Pruned vs full node

Bitcoin Core offers two storage philosophies: keep everything (full node) or validate everything but delete old block files (pruned node). Marketing blurs them. Wallets panic about "not a full node" as if pruned means trusting someone else. That is wrong. Both modes independently enforce Bitcoin's rules. The fork in the road is disk, bandwidth, and what companion services you want.

What pruned mode actually does

With prune=550 (or higher), Bitcoin Core downloads and verifies each block, updates the UTXO set, then discards block files older than the pruning window. You retain only recent blocks on disk — roughly 7–10GB of block data plus indexes and overhead in mid-2026 configurations, though plan 15–20GB for comfort on VPS images.

You cannot serve deep historical block queries to other software, but you can validate that new transactions pay valid UTXOs and that new blocks follow consensus.

What full mode adds

A full node retains the entire chain back to genesis. As of June 2026, expect about 750GB on disk for chain data alone, trending upward. Add 100GB+ headroom for logs, indexes, and OS. On hardware, a 1TB NVMe is the practical minimum; 2TB is peace of mind if you run Electrs or other indexers.

Full history enables archival lookups, block explorers on your LAN, and some analytics tools that walk ancient transactions without re-downloading.

Trust model — the part people get wrong

Security for validation means your node checks signatures and consensus rules without relying on a remote server. Pruned nodes do that. You are not "trusting Blockstream" when pruned — you are trusting your own verified UTXO state.

Where pruned nodes differ: you cannot independently serve arbitrary old block heights to other apps without fetching them again. If your threat model includes "prove block 150,000 existed offline forever," you want full storage.

Bandwidth implications

Initial sync downloads the entire chain either way. Pruned mode still pulls historical blocks during IBD, then deletes them. Full mode keeps them. Ongoing traffic is similar for basic validation — a few GB per month relaying blocks and transactions unless you run heavy indexes.

On VPS, the pain is initial sync egress: 600–750GB transfer in a week can trigger caps on budget hosts. Model this on our VPS comparison before assuming unlimited means free at sync time.

Disk IO during initial block download

Both modes hammer disk during IBD. Slow USB2 enclosures and SD cards are the real enemy — not pruned vs full. NVMe on Pi 5 (M.2 HAT+) or a mini PC SATA/NVMe combo matters more than the prune flag. We do not publish fake MB/s benchmarks; expect "varies by disk" and favor NVMe for sync sanity.

Who should run pruned

• Home users validating their own wallet with limited disk
• VPS users on 40–80GB plans (Hetzner CX23, Contabo entry tiers)
• Raspberry Pi setups where 1TB NVMe is overkill for the use case
• Anyone who does not query ancient blocks

Who should run full

• Archival interests — you want local history without re-fetch
• Running Electrum personal server, mempool.space self-hosted, or analytics
• Multiple services sharing one large SSD/HDD pool
• You already bought a 2TB disk — storage is cheap relative to your time

Config snippet

# Pruned (minimum target 550 MiB — Core rounds up)
prune=550

# Full — omit prune= line entirely
# Ensure 850GB+ free space before starting IBD

See the full walkthrough in our setup guide. Bitcoin Core 28.x is the stable reference for mid-2026 — always verify the latest release at bitcoincore.org before install.

Managed platforms

Start9 and Umbrel often default to configurations aimed at app stores. Check whether their "full node" toggle actually fits your disk before enabling Lightning + Electrs + everything else. A pruned base with selective services beats a full node that runs out of space mid-sync.

Decision shortcut

If you hesitated reading this paragraph because 750GB sounds abstract, start pruned. You can replan for full storage later with a bigger disk and patience for another historical download. If you already own a 2TB NVMe and run indexing software, go full and skip the re-sync regret.

FAQ