Live prices are currently unavailable — the exchange feed could not be reached and no recent cached reading is held.

Bitcoin Data GuideBitcoin Reference

Node Operations

Node Storage Requirements

Storage is the resource that decides whether a node can keep the whole chain or has to prune. The full chain grows continuously, so any figure quoted for it is a snapshot. What does not change is the trade-off: pruning lowers the disk requirement by giving up the ability to serve old blocks.

Last reviewed 2026-09-21Source: Bitcoin Core pruning documentation; Bitcoin Core release notesChain size grows continuously, so no absolute figure is quoted here; the trade-off is what is described.

Keeping the whole chain

A node that keeps the whole chain stores every block from the genesis block to the tip, along with the index structures it needs to look up transactions and outputs. The chain grows with every block, so the requirement is a moving target: a disk that was generous when the node was set up may be tight a few years later. The practical advice is to size the disk with headroom rather than to the current figure.

The index structures are a meaningful part of the total. A node needs to be able to answer questions such as whether a given output has been spent, and doing that efficiently requires data beyond the raw blocks. The chainstate and the block index together add a substantial fraction to the size of the block data itself, which is why the disk requirement is larger than the sum of the block files.

Keeping the whole chain is what allows a node to serve historical blocks to other nodes and to rescan its own wallet history from any point. Those are the capabilities that pruning gives up, and whether they matter depends on what the operator wants the node to do.

Pruning

Pruning lets a node validate the whole chain and then discard the block data it no longer needs, keeping only the recent blocks and the state needed to validate new ones. The node still performs the full initial block download and still enforces every consensus rule; what it gives up is the ability to serve old blocks to other peers and to rescan its own history from an arbitrary point.

The disk requirement under pruning is set by the operator rather than by the size of the chain. A node can be configured to keep a few gigabytes of recent blocks, which makes it possible to run a validating node on hardware that could never hold the full chain. That is the main reason pruning exists: it lowers the barrier to running a node without weakening the validation the node performs.

The trade-off is real but narrow. A pruned node is a full validating node in every respect that matters for verifying new transactions and blocks. It is not a full archival node, and it cannot answer a request for a block it has discarded. For a user who wants to verify their own transactions, pruning is usually sufficient; for someone running a block explorer or serving historical data, it is not.

Choosing a mode

The choice between a full archival node and a pruned one is the main storage decision an operator makes, and it is worth making deliberately rather than by default. A full node needs a disk that will remain adequate as the chain grows, and it can serve historical data. A pruned node needs far less space and can run on modest hardware, at the cost of the historical data.

There is a middle option in the form of a node that keeps the full chain but disables the transaction index, which saves the space the index would occupy at the cost of slower lookups by transaction identifier. The index is a convenience rather than a requirement for validation, so disabling it is a reasonable choice for an operator who does not need the lookup.

Whatever mode is chosen, the storage decision interacts with the initial sync covered on the initial block download page. A pruned node still downloads and validates every block; it simply does not keep them all. The validation is not reduced, only the retention.

Sources and references

The description of the storage modes and the pruning behaviour is taken from the Bitcoin Core documentation. No specific disk size is asserted, because the chain grows and any figure would be stale.

  • Pruning and the storage modes. Bitcoin Core, Bitcoin Core documentation: documents the pruning option, the block retention it controls and the reduced-disk mode.
  • The block and chainstate structures. Bitcoin Core, Bitcoin Core developer notes: describes the block index and chainstate that account for the storage beyond the raw block files.
  • The validation a pruned node still performs. Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System: states the validation rule that every node applies regardless of how much history it retains.

Related reading