Sui Storage Cost
The cost of operating on any blockchain has two main components: compute, the power required to process logic, and storage, the digital space needed to store data and results.
Compute is relatively fixed on Sui, with hundreds of validators running 24-core, 128GB RAM machines.
Because Sui achieves high throughput compared to other blockchains, storage costs can vary significantly.
The following table summarizes the main storage components:
| Storage category | Storage type | Usage description | Mainnet storage needs (as of May 2024) |
|---|---|---|---|
| Validators | RocksDB, SSD storage | Validators store the latest consensus data on high-performance NVMe disks. | ~200GB |
| Pruning full nodes | RocksDB, SSD storage | Pruning full nodes maintain unpruned RocksDB indexes for efficient querying. | ~1.6TB |
| Unpruned full nodes | RocksDB, SSD storage | Unpruned full nodes retain full object and transaction history for complete archival. | ~4.9TB |
| Full node snapshots | Cloud storage | Snapshots of full node data are stored in cloud storage for validator or full node backup and recovery. | ~1.6TB |
| State-sync archival | Cloud storage | State-sync archival stores blockchain state data in cloud storage to support syncing of historical objects that may have been pruned. | ~1.3TB |
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.
The image above shows Mainnet growth in 2024:
- Over a 90-day period with ~18 TPS, disk usage increased from 203GB to 215GB (~130MB per day).
- Over a two-week period with ~183 TPS, disk usage grew from 215GB to 271GB (~4GB per day).
These results show storage growth increases relative to TPS rates.
Pruning full nodes
Pruning full nodes are similar in disk usage to validators because pruning settings are the same. There are two 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 ~1.6TB. With indexing disabled, usage is ~100GB.
Unpruned full nodes
Unpruned full nodes are uncommon and apply to a few use cases:
- You need the entire chain state on one machine.
- 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 two 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 (as of May 2024).
State-sync archival
State-sync archival 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).
Related links
Establishing a custom indexer helps improve latency, allows pruning the data of your Sui full node, and provides efficient assemblage of checkpoint data.
Database snapshots of the Sui network enable full node operators a way to bootstrap a full node without having to execute all the transactions that occurred after genesis.
The archive is a historical record of all transactions on Sui. Enable archiving on your Full nodes as a best practice.