Bitcoin Node Storage Calculator: Disk Space by Pruning Level

Bitcoin Node Storage Requirements in 2026

Running a Bitcoin full node requires dedicating disk space to store blockchain data, the UTXO set, and index files. As of August 2026, the Bitcoin blockchain occupies approximately 760 GB on disk for a full archival node. That number grows by 70 to 82 GB per year, meaning storage planning is critical for anyone setting up a node that needs to run reliably for multiple years.

The total disk space your node requires depends on one key configuration choice: pruning level. A pruned node discards old block data after validating it, keeping only the UTXO set and a configurable window of recent blocks. An archival node retains every block since genesis. Both types validate the full blockchain during initial block download (IBD) and enforce identical consensus rules.

Storage by Node Configuration

The following table breaks down disk space requirements for each common Bitcoin Core configuration. The "Block Data" column shows how much raw block and undo data is retained on disk. The "Chainstate" column reflects the UTXO set database, which every node must maintain regardless of pruning. Total disk usage includes block data, chainstate, indexes, and overhead.

Note: The prune value in bitcoin.conf is specified in megabytes of raw block and undo data. The minimum allowed value is 550 MiB. Pruning is incompatible with txindex.

Projected Blockchain Size: 2027 to 2030

Bitcoin's blockchain has grown at an average rate of 70 to 82 GB per year since 2024. The growth rate depends on average block size, which fluctuates with transaction demand, Ordinals inscription activity, and fee market dynamics. Average block sizes in 2025 and 2026 have ranged between 1.6 and 1.9 MB, down from a peak of 2.29 MB in March 2024 during the height of the inscription boom.

The following projections assume a steady-state growth rate of 75 GB per year. Actual growth could be higher if inscription-style protocols drive average block sizes toward the 4 MB weight limit, or lower if fee pressure prices out non-financial data.

The blockchain is projected to cross the 1 TB threshold around late 2028 or early 2029. A 2 TB SSD purchased today provides approximately 5 years of headroom for an archival node. The minimum pruned size grows slowly because it is dominated by the chainstate database, which expands as the UTXO set grows.

UTXO Set Size and Memory Requirements

Every Bitcoin node maintains a database of all unspent transaction outputs: the UTXO set. As of April 2025, the set contained approximately 173 million UTXOs, occupying roughly 11 GB on disk in Bitcoin Core's LevelDB chainstate database. The full UTXO set, if loaded entirely into memory, would require approximately 30 GB of RAM.

In practice, Bitcoin Core does not load the entire UTXO set into memory. It caches a portion controlled by the dbcache setting (default: 450 MB, automatically raised to 1,024 MB on systems with 4+ GB of RAM). A larger dbcache improves IBD performance: benchmarks show a 28 GB cache completes sync roughly 24% faster than the 450 MB default. For ongoing operation after sync, 450 MB to 1 GB of cache is sufficient.

Practical RAM recommendations for 2026:

• Pruned node: 4 GB minimum, 8 GB recommended
• Archival node: 8 GB minimum, 16 GB recommended
• Node + Lightning (e.g., LND or Core Lightning): 16 GB recommended

AssumeUTXO: Fast Bootstrapping

AssumeUTXO is a feature introduced in Bitcoin Core v28.0 that allows a node to load a pre-computed snapshot of the UTXO set and begin validating new blocks within minutes rather than days. The node downloads a snapshot file (approximately 7 to 12 GB depending on the block height), verifies its hash against a value hardcoded in the Bitcoin Core source, and syncs forward from the snapshot height to the current chain tip.

A full background IBD from genesis runs concurrently after the snapshot is loaded. When the background sync reaches the snapshot height, it independently verifies that the computed UTXO set matches the snapshot hash. This means AssumeUTXO nodes eventually reach the same security level as nodes that performed a traditional IBD.

In real-world benchmarks, AssumeUTXO reduced time-to-usable-node from roughly 11 hours to approximately 94 minutes on desktop hardware: 10 minutes for snapshot loading plus 84 minutes to sync from the snapshot height to the chain tip. Storage requirements remain similar to a standard archival node because the background IBD downloads the full blockchain.

SSD vs. HDD Performance

An SSD is effectively mandatory for running a Bitcoin node in 2026. The IBD process involves heavy random I/O as the node reads, validates, and writes millions of UTXO entries. HDDs handle sequential reads adequately but struggle with random access patterns, turning what should be a multi-hour sync into a multi-week ordeal.

After IBD completes, ongoing storage I/O requirements drop significantly. A SATA SSD is sufficient for steady-state block validation. However, if you plan to re-sync or need to perform a reindex, NVMe saves substantial time. For hardware comparisons across popular node builds, see the Bitcoin node hardware comparison.

Choosing the Right Configuration

The optimal node configuration depends on your use case:

Personal validation and privacy: a pruned node at prune=550 or prune=1000 validates every block and enforces all consensus rules identically to an archival node. It runs comfortably on a 128 GB drive and is the lowest-cost way to verify your own transactions without trusting a third party.

Supporting the network: an archival full node serves historical blocks to peers performing IBD. If you want to contribute to Bitcoin's decentralization, running an archival node with upload bandwidth helps new nodes sync. Budget for a 2 TB SSD and 150+ GB of monthly upload bandwidth.

Running services on top: if you plan to run a block explorer, Electrum server, or blockchain indexer, you will need an unpruned node with txindex=1 enabled. Budget for at least 1 TB now, with a plan to upgrade to 2 TB before 2029.

For a comparison of node software options (Bitcoin Core, Bitcoin Knots, btcd, and others), see the Bitcoin node software comparison.

IBD Time Estimates by Hardware

Initial block download time varies dramatically based on hardware. CPU is often the bottleneck, not storage or bandwidth, because every block must be validated and every signature checked. The following estimates reflect real-world benchmarks from 2025 and 2026.

IBD times have increased substantially over the years. What took 3 days in 2022 may take 7+ days on the same hardware in 2026 due to the growth in block count and UTXO set size. For a detailed look at how different node implementations handle sync, see our research on Bitcoin node implementation comparison.

Bandwidth Requirements

Beyond storage, bandwidth is a significant consideration. The IBD itself requires downloading approximately 760 GB of block data (or more with overhead). After sync, ongoing bandwidth depends on whether you run a listening node (accepting inbound connections) or a non-listening node.

• IBD download: ~760 GB one-time
• Daily download (blocks + transactions): 250 to 500 MB
• Daily upload (serving peers, listening node): up to 5 GB
• Daily upload (non-listening node): ~10 MB
• Monthly total (listening node): 150+ GB upload, 8 to 15 GB download

Users on metered connections should consider running a non-listening node or setting maxuploadtarget in bitcoin.conf to cap upload bandwidth.

Frequently Asked Questions

How much storage does a pruned Bitcoin node need?

A minimally pruned Bitcoin node (prune=550) requires approximately 12 GB of total disk space in 2026. This includes 550 MB of retained block data and roughly 11 GB for the UTXO set chainstate database. Larger prune values retain more block history: prune=10000 uses about 22 GB total.

How big is the Bitcoin blockchain in 2026?

The Bitcoin blockchain is approximately 760 GB as of August 2026. It grows by roughly 70 to 82 GB per year, depending on average block size and transaction volume. At current growth rates, it will cross 1 TB around late 2028 or early 2029.

Can I run a Bitcoin node on a 1 TB drive?

Yes, but with limited runway. A 1 TB drive holds the current 760 GB blockchain plus chainstate and indexes, leaving approximately 200 GB of headroom. At 75 GB of annual growth, you would need to upgrade or enable pruning within 2 to 3 years. A 2 TB drive is the recommended minimum for an archival node intended to run through 2030.

Do I need an SSD to run a Bitcoin node?

An SSD is strongly recommended and practically required in 2026. The initial block download involves intensive random I/O that HDDs handle poorly, often turning a multi-hour sync into a multi-week process. After IBD, a SATA SSD is sufficient for steady-state operation. NVMe provides faster sync and reindex times.

What is AssumeUTXO and does it reduce storage requirements?

AssumeUTXO is a Bitcoin Core feature that loads a pre-computed UTXO set snapshot, allowing a node to begin validating new blocks within minutes instead of hours or days. It does not reduce storage requirements for an archival node because a full background IBD still downloads all historical blocks. However, it dramatically reduces time-to-usable-node: approximately 94 minutes versus 6 to 10+ hours for traditional IBD on desktop hardware.

Does a pruned node validate the entire blockchain?

Yes. A pruned node downloads and validates every block from genesis during IBD, exactly like an archival node. The only difference is that it discards old block data after validation, retaining only the UTXO set and a configurable window of recent blocks. A pruned node enforces all consensus rules and provides the same security guarantees for its operator as an archival node.

How much RAM does a Bitcoin full node need?

Bitcoin Core's official minimum is 512 MB of RAM with default settings, but practical minimums are higher in 2026. A pruned node should have at least 4 GB of RAM (8 GB recommended). An archival node benefits from 8 GB minimum, with 16 GB recommended if running alongside a Lightning node or other services. Increasing the dbcache setting during IBD can reduce sync time by up to 24%, but requires corresponding RAM.

This tool is for informational purposes only and does not constitute financial or technical advice. Storage estimates are based on publicly available data as of August 2026 and may vary based on future network activity. Always verify current blockchain size and hardware requirements before purchasing equipment. Growth projections assume historical averages and actual results will differ.