What it takes to run a Sui full node in 2026: Mysten's hardware spec, how disk grows with and without pruning, snapshot restore versus syncing from genesis, and where the real cost sits.
Running your own Sui full node is a reasonable choice for some teams and an expensive habit for others. The hardware spec is public and short. What is not obvious from the spec is how the machine behaves six months in: how fast the disk fills, what pruning takes away, how a fresh node catches up, and which parts of the bill are hardware and which are people. This guide covers all of it, with the numbers taken from Sui's own operator documentation and the judgement calls marked as ours.
TL;DR:
Sui's operator guide lists a suggested minimum for a full node:
| Resource | Suggested minimum |
|---|---|
| CPU | 8 physical cores / 16 vCPUs |
| RAM | 128 GB |
| Storage | 4 TB NVMe SSD |
| OS | Linux (Ubuntu or Debian supported) |
macOS is supported for development only. The guide is explicit that these are suggestions rather than hard limits, and in practice two things push you above them.
The first is RPC traffic. A node that only follows the chain has a predictable load. A node that also answers gRPC or GraphQL queries for an application has a load shaped by your users, and the indexes it maintains to answer those queries need their own disk and memory. Sui's documentation notes that indexing for RPC requests needs additional storage without putting a number on it, because the number depends on what you query.
The second is headroom during upgrades and compaction. RocksDB compaction after a pruning change can run for days, and a node at the edge of its memory budget will show it as latency before it shows it as an error.
Disk growth. The 4 TB figure assumes pruning is configured and active. Sui's own troubleshooting table lists "disk full (7TB+)" with the cause "pruning not configured or not active". If you start a node with default settings and never revisit them, the disk is a countdown timer.
Pruning is a product decision, not an ops setting. Pruning is controlled by how many epochs the node retains. Retain few and the working set stays small, but the node can no longer answer for anything older. Retain many and you are back to buying disk. Sui's guidance for historical reads is to "query the Archival Service for historical data, or increase num-epochs-to-retain". Either way, someone has to decide how much history your product needs, and that decision moves the hardware line.
Snapshots. A new node should be restored from a snapshot, not synced from genesis. The guide says so directly: "restore from a snapshot rather than syncing from genesis". There are two kinds. Formal snapshots contain only what is needed to restore a valid state at an epoch, are verified against the committee's commitment during restore, weigh around 30 GB for a recent mainnet epoch, and restore fastest; Sui notes they are not suitable for an RPC node that does historical lookups. Database (RocksDB) snapshots are a point-in-time copy of the store including non-pruned data and indices, so they are larger but keep an RPC node's history. Either way, plan for the download and for the catch-up window afterwards, during which the node is not yet serving current data.
Compaction after changes. Applying a pruning configuration to a node that has grown large does not free space immediately. Sui's guide asks operators to allow 3 to 5 days for compaction to reclaim it. Budget disk for the before state, not the after state.
Protocol upgrades. Sui publishes new node releases regularly, and a node has to be running a binary that supports the current protocol version to keep following the chain. In our experience this is the most common way a self-run node goes quietly stale: nobody rolled the release in time.
A pruned full node is a live-state machine. It answers "what is this object now" and "what happened in the last N epochs". It does not answer "show me this wallet's activity since 2023", "replay every event from this package since launch", or "what was this object's version at checkpoint 40 million".
Those questions need archival depth: every checkpoint, transaction and object version since genesis, indexed so a query does not turn into a scan. On a self-run setup that means either a second, unpruned node whose disk you keep buying, or an archival store alongside the node. It is the part of the stack that grows without bound, and the part most teams underestimate when they price "just run a node".
For comparison, every Inodra gateway serves full history since genesis on the same endpoint as live data, with routing to live node or archival storage handled per request. The endpoints page lists the URLs.
The hardware line is easy to price: a bare-metal machine at or above the spec, plus NVMe, plus egress. Providers publish those numbers and they are not the surprising part.
The surprising part is everything else:
Written out, the operations budget tends to exceed the hardware budget within the first year (our observation from running the Inodra fleet, not a published figure), and it scales with the number of nodes rather than with traffic.
It does, for some teams:
If none of those apply, the two managed shapes below are almost always cheaper once the operations are counted.
Shared gateway. One API key, every protocol (gRPC, GraphQL, JSON-RPC), full history since genesis, no node to run. Rate limits and credits scale by plan, from a free tier with no credit card to enterprise limits. This is the right default for most applications, and the endpoints page has everything needed to make the first call.
Dedicated node. When a shared rate limit or latency profile is the bottleneck, or when you need archival mode, RPC tuning or a custom patch, a dedicated node gives you bare-metal hardware and a private endpoint with no shared rate limit. Inodra patches and monitors it; the configuration is yours. It is priced per region and delivered within 6 to 24 hours of purchase, and it stacks with a plan, so the shared gateway keeps handling reads while the latency-sensitive path goes to your own hardware.
The choice between the two is covered in more detail in Sui RPC node options: public, managed, or dedicated.
What hardware do I need to run a Sui full node? Mysten's suggested minimum is 8 physical cores (16 vCPUs), 128 GB of RAM and a 4 TB NVMe drive, on Ubuntu or Debian. Treat it as a floor: a node that also serves RPC traffic wants headroom on all three.
How much disk does a Sui full node use? It depends entirely on pruning. Without pruning configured, operators report disks filling past 7 TB. With pruning on and a modest number of epochs retained, the working set stays within the 4 TB spec, at the cost of serving no old history.
How long does a Sui full node take to sync? Sui's operator guide tells you to restore from a snapshot rather than sync from genesis. A formal snapshot for a recent mainnet epoch is around 30 GB and restores fastest; a database snapshot is larger but keeps the indices an RPC node needs for historical lookups.
Can a pruned Sui full node serve historical data? No. A pruned node only answers for the epochs it retains. Older checkpoints, transactions and object versions need an archival service or a node configured to keep every epoch, which is where the storage bill comes from.
Four ways to get a Sui RPC node, compared: the Foundation's public endpoints, your own full node, a managed RPC node provider, or a dedicated node. Setup, limits, history and cost.
Sui JSON-RPC is deprecated and gone from public fullnodes. Inodra still serves the API on mainnet and testnet, with history back to genesis.
All 14 providers on Mysten Labs' official Sui gRPC list compared on gRPC, GraphQL, archival depth, streaming and webhooks, plus JSON-RPC continuity for legacy clients.