How is Sui different from Solana?

Sui and Solana are both high-throughput layer 1 chains with parallel execution, but they're built differently. Solana programs are usually written in Rust (often with Anchor) and work on accounts. A Sui contract is a Move package, and its data lives in typed objects that each have an owner. Sui transactions are also composed differently: a programmable transaction block (PTB) can chain up to 1,024 calls, where Solana composes programs through cross-program invocations (CPIs).

Data model: accounts vs objects

On Solana everything is an account: programs, data and wallets. Programs are stateless and change the accounts passed to them. Access control comes down to program logic and signer checks, often through program-derived addresses (PDAs).

On Sui everything is an object with an ID, a version and an owner. That owner can be an address, another object, or the object can be shared or immutable. Move packages hold the logic, and objects hold the data. Access is usually gated by capability objects: a function takes &AdminCap, and only whoever owns that object can call it. See object ownership.

Move

module example::admin;

public struct AdminCap has key { id: UID }

// Only the holder of AdminCap can call this
public fun set_fee(_: &AdminCap, config: &mut Config, fee: u64) {
    config.fee = fee;
}

public struct Config has key { id: UID, fee: u64 }

Composition: CPIs vs PTBs

A Solana program calls other programs through CPIs, which nest up to 4 levels deep, and every account involved has to be passed in carefully. On Sui, composition usually happens client-side. A PTB chains up to 1,024 Move calls and built-in commands, feeds one call's output into the next, and runs them all atomically.

Parallel execution

Both chains run non-conflicting transactions in parallel. Solana's Sealevel runtime needs every account a transaction touches declared upfront. Sui transactions declare their input objects, and transactions that touch only owned objects don't contend with anyone else. Shared objects are ordered by consensus. See shared vs owned objects.

Consensus and finality

Solana uses a rotating leader that produces blocks, and validators vote on them through Tower BFT. Sui uses Mysticeti, a DAG-based protocol where every validator proposes blocks in parallel. Sui's docs put end-to-end finality at typically 400–700 ms. See how fast Sui finalizes.

Storage costs

Solana accounts have to hold a minimum balance to be rent-exempt. On Sui you pay a storage fee upfront when you create data, and you get most of it back as a rebate when you delete the object. See the storage fund.

Tokens and NFTs

Solana has SPL Token, Token-2022 and Metaplex standards. Sui has the currency standard (Coin<T>) and Closed-Loop Token, and NFTs are plain objects. Sui enforces royalties on-chain through Kiosk transfer policies. On Solana they depend on standards like MPL Core or Token-2022 extensions.

Tooling

	Solana	Sui
Contract language	Rust (Anchor)	Move
CLI	Solana CLI, Anchor	Sui CLI
Client SDKs	Rust, TypeScript, Python, Go	Rust, TypeScript, Python (and community SDKs)
Querying	RPC plus third-party indexers	gRPC, GraphQL, custom indexers

To try Sui, install the CLI, get testnet SUI and run transactions in the playground.

Sources

Solana to Sui, Sui documentation
Consensus, Sui documentation
Transaction life cycle, Sui documentation