Skip to main content

Storage

The cost of operating on any blockchain has two main components: compute, the power required to process logic (transactions), and storage, the digital space needed to store data and transaction results.

Storage architecture​

The following table summarizes the main storage components:

Storage categoryStorage typeUsage descriptionMainnet storage needs (as of November 2025)
ValidatorsRocksDB, SSD storageValidators store the latest consensus data on high-performance NVMe disks.~250-400GB
Pruning full nodesRocksDB, SSD storagePruning full nodes maintain unpruned RocksDB indexes for efficient querying.2.5TB
Unpruned full nodesRocksDB, SSD storageUnpruned full nodes retain full object and transaction history for complete archival.16TB
Full node snapshotsCloud storageSnapshots of full node data are stored in cloud storage for validator or full node backup and recovery.~1.6TB
Checkpoints bucketCloud storageStores blockchain state data in cloud storage to support syncing of historical objects that might have been pruned.~30TB

Validators​

Validators should enable pruning to limit database growth. Transaction-per-second (TPS) rates affect growth, but storing full transaction and object history is the main factor. Transaction type also influences data growth.

Pruning full nodes​

Pruning full nodes are similar in disk usage to validators because pruning settings are the same. There are 2 exceptions:

  • Full nodes keep a consensus_db, which accounts for about half of validator disk usage.

  • If the node serves RPC queries, the indexes/ directory in Mainnet consumes significant space. Currently, indexes/ is 1.5TB and grows with TPS.

The total disk usage of a pruned full node with indexes is 2.5TB. This is the size of a single epoch's database snapshot.

Unpruned full nodes​

Unpruned full nodes are uncommon and apply to a few use cases:

  1. You need the entire chain state on one machine.

  2. You want to enable state-sync without using a cloud archival fallback. Using an unpruned node as a peer avoids configuring an archival bucket.

Growth examples:

  • Over a 90-day period with ~18 TPS, usage increased from 3.4TB to 4.34TB (~10GB per day).

  • Over a two-week period with ~183 TPS, usage grew from 4.34TB to 4.92TB (~40GB per day).

Full node snapshots​

There are 2 types of snapshots:

  • Database snapshots: Equal in size to the database of the full node that produced them (1:1 copy).

  • Formal snapshots: Lightweight, ~30GB for recent Mainnet epochs.

Checkpoints bucket​

The checkpoints bucket stores blockchain state data in a cloud storage bucket written by a full node or ingestion daemon.

Growth examples:

  • Over a 90-day period, usage increased from 867GB to 1.18TB (~3GB per day).

  • Over a two-week period, usage grew from 1.18TB to 1.32TB (~10GB per day).

Cost of storage​

Every transaction that creates or modifies objects incurs a storage fee.

Compute is relatively fixed on Sui, with hundreds of validators running 24-core, 128GB RAM machines. However, because Sui achieves high throughput compared to other blockchains, storage costs can vary significantly. Periodically, a governance proposal on the network sets the storage fee, however there are some underlying factors that contribute to the data storage measurement.

Currently, the storage fee is 76 MIST or 0.000000076 SUI per storage unit.

tip

You can check the current storage fee on the network using the following GraphQL query:

{
  protocolConfigs {
    config(key: "storage_gas_price") {
      value
    }
  }
}

You can run this query in your browser at https://graphql.mainnet.sui.io/graphql

The total storage fee for a transaction is charged as part of the transaction's total gas fee.

Storage fund​

The total cost of storage for a transaction is based on each storage unit used in the transaction. Every byte of data is equal to 100 storage units. For reference, a kilobyte is equal to 100,000 storage units. If a transaction included a 1 kilobyte object, the storage fee would equal 7.6 million MIST or 0.0076 SUI.

This fee is split into 2 parts:

  1. Refundable deposit: Locked in the storage fund while the object exists. If the object is deleted or reduced in size, some of this deposit is returned as a storage rebate.

  2. Non-refundable fee: Permanently locked in the storage fund, removing that SUI from circulation forever.

The storage fund is designed such that the network's current validators process and store data, but future validators are incentivized to maintain it. If users only paid when they store data on-chain, future validators would front the cost of storage without reimbursement. The storage fund resolves this by collecting fees when data is first stored, then redistributing it to validators throughout the entire time the data exists.

The storage fund is locked and staked each epoch to compensate active validators. Excess staking rewards earned by the storage fund are reinvested back into it, ensuring the storage fund has the capability needed to compensate validators.

Storage rebates​

The design of the storage fund also incentivizes users to delete data if the cost of storing it exceeds the value of keeping it on-chain. By offering a rebate on storage fees, the system encourages users to free up space.

If data is deleted from Sui, it would stop using storage resources and a portion of the original storage fee, currently set at 99%, would be returned to the gas fee payer as a rebate. The non-refundable portion of the storage fee (1%) is never returned. Immutable objects lock both their storage fee forever and cannot receive a rebate, as they cannot be deleted or modified.

•
Sui Storage Fund: Bringing Deflationary Pressure to SUI

Learn how the storage fund creates deflationary pressure on SUI tokens.

•
Sui Storage Fund Demystified

Understand the mechanics of the Sui storage fund.

•
Storage Fees on Sui Explained

Detailed explanation of how storage fees work on Sui.