On this page 8 sections
A Bitcoin full node is light on CPU and memory but heavy on disk and upload. Bitcoin Core needs only 2 GB of RAM and 7 GB of disk in pruned mode, but an unpruned node stores the whole chain: about 768 GB in September 2026, growing roughly 80 GB a year. Add an Electrum server index if wallets connect to it, and expect to upload 200 GB or more a month.
The short version
| Setup | Disk | RAM | CPU | Bandwidth |
|---|---|---|---|---|
| Pruned node (validates everything, keeps recent blocks) | about 7 GB of block data, plus the chainstate; an SSD | 2 GB minimum | Any modern CPU | About 740 GB once for the initial download |
| Full archival node | 1 TB NVMe today, 2 TB to last several years | 8–16 GB | 4+ cores make the initial sync faster | About 20 GB down and 200 GB+ up a month |
| Full node + Electrum server (Fulcrum or Electrs) + Lightning | 2 TB NVMe | 16–32 GB | 4–8 cores | Same, plus your wallets’ traffic |
| Explorer or several services (mempool, indexers, other chains) | 4 TB NVMe | 64 GB+ | 8–16 cores | Unmetered recommended |
Disk: the chain, its growth and pruning
The Bitcoin block chain measured about 768 GB on September 11, 2026, up from about 686 GB a year earlier, according to YCharts: roughly 12%, or 80 GB, a year. Bitcoin.org’s own full-node guide puts the initial block download at roughly 740 GB and total disk use at over 750 GB, before any optional index.
Pruning keeps the node fully validating while deleting old blocks once they are processed. Set prune=550 (the minimum, in MiB) in bitcoin.conf and block data shrinks from over 750 GB to around 7 GB. The catch: a pruned node cannot serve old blocks to peers, and pruning is incompatible with txindex and wallet rescans, so it cannot back an Electrum server or a block explorer.
Indexes add to the chain. An Electrum server indexes every address so that wallets such as Sparrow or Electrum can query your node privately. In Sparrow Wallet’s benchmark, Electrs used 32 GB and does not need txindex, while Fulcrum used 102 GB and does. That benchmark dates from February 2022, when the chain was much smaller, and both indexes have grown with it since, so budget generously.
Speed matters during the first sync. Bitcoin.org sets a floor of 100 MB/s for the disk. In practice the initial sync reads and writes the UTXO set constantly, and an NVMe SSD can turn days of syncing on a hard disk into hours. After the sync, the load is light.
CPU and memory
Once synced, Bitcoin Core uses a fraction of one core. The initial sync is where CPU and memory pay off: script verification runs in parallel across cores, and a larger database cache (the dbcache setting, in MiB) keeps more of the UTXO set in memory and avoids repeated disk writes. A common approach is to raise dbcache to several gigabytes for the initial sync, then lower it again.
Bitcoin.org lists 2 GB of RAM as the minimum for Bitcoin Core alone. Running Fulcrum, a Lightning node, a mempool explorer and monitoring next to it is what pushes a box to 16 or 32 GB.
AssumeUTXO: a usable node in hours
Since Bitcoin Core 28.0, released on October 2, 2024, the loadtxoutset RPC accepts a UTXO set snapshot on mainnet. The software ships with the hash of a snapshot at block 840,000 and refuses any file that does not match it. The node is usable as soon as the snapshot is loaded and catches up from that height, while it validates the full history from genesis in the background. The snapshot itself is not bundled: you obtain the file separately, and Bitcoin Core checks it before use. Newer releases may accept more recent snapshot heights; their release notes list them.
Bandwidth and traffic
Bitcoin.org’s figures: an upload speed of at least 400 kbit/s, about 20 GB of download a month after the initial 740 GB, and, for nodes on high-speed connections, 200 GB of upload a month or more. Upload is what a well-connected node gives back to the network, by serving blocks to new nodes. On a metered plan it is the line that grows; on an unmetered port you can leave inbound connections open without counting. You can cap upload with Bitcoin Core’s maxuploadtarget option if you must.
Which server for which node
| Use | Configuration | Disk layout | Price |
|---|---|---|---|
| Full node, Electrs and a Lightning node | Ryzen 7 7700, 8 cores, 64 GB DDR5 | 2 × 1 TB NVMe as one 2 TB volume | $79/mo |
| Full node with Fulcrum, a mempool explorer and room to grow | Ryzen 9 9950X, 16 cores, 128 GB DDR5 | 2 × 1.92 TB NVMe, mirrored | $159/mo |
| Several chains, indexers or a public explorer | EPYC 9454P, 48 cores, 256 GB ECC | 2 × 3.84 TB NVMe | $489/mo |
A note on redundancy: the chain itself can always be downloaded again, so a mirror protects your uptime, not your data. What you must back up separately is what cannot be recreated: wallet files and, above all, Lightning channel backups. For a pruned node only, the Ryzen 5 7600 at $55 a month is plenty.
A sensible starting configuration
# ~/.bitcoin/bitcoin.conf: full archival node that also serves an Electrum server
server=1
txindex=1 # needed by Fulcrum and explorers, not by Electrs
dbcache=4096 # MiB; raise it for the initial sync, lower it afterwards
listen=1 # accept inbound peers on port 8333
maxconnections=125
# prune=550 # instead of txindex, for a pruned node with no index- Open TCP port 8333 for inbound peers, and keep the RPC port bound to localhost.
- Run the daemon as an unprivileged user and follow our first-hour hardening checklist.
- Monitor free disk space: the chain grows every block, and an index that runs out of space has to be rebuilt.
Paying for the server in bitcoin is an option too: see how BTC payments work here. For other chains, read our Ethereum and Solana hardware guides, or blockchain node hosting.
Sources
- Running a full node — Bitcoin.org
- Bitcoin Blockchain Size — YCharts (September 11, 2026)
- Bitcoin Core 28.0 release notes — Bitcoin Core, October 2, 2024
- Server performance — Sparrow Wallet (February 2022)
