Ethereum Archive Node Disk Size 2026 vs Erigon Archive Node Disk Size 2026 vs Geth Full Node Disk Size 2026

Summary: As of January 7, 2026, Ethereum archive storage has shifted dramatically: Geth’s new path‑based archive mode cuts disk to roughly 2 TB, while Erigon’s archive footprint sits in the 1.8–2.2 TB range; a snap‑synced, periodically‑pruned Geth full node remains near 650–700 GB. This guide compares sizes, trade‑offs, costs, and deployment patterns so you can choose the right setup for production.

What changed since 2024–2025

Geth introduced a path‑based archive mode that stores historical state as reverse diffs, reducing full‑history archive storage from multi‑tens of TB (legacy hash‑based) to about 1.9–2.0 TB on mainnet, with one key caveat: historical Merkle proofs (eth_getProof) are not yet supported in this mode. (geth.ethereum.org)
Erigon 3 (“Caplin” storage) stabilized its storage profile and publishes up‑to‑date, measured disk usage; mainnet archive is listed around 1.77 TB, full ≈920 GB, minimal ≈350 GB (values as of late 2025). (docs.erigon.tech)
Geth full nodes still land around >650 GB when snap‑synced and pruned; with default cache, growth is ~14 GB/week until you run an offline prune (plan headroom or prune on a schedule). (geth.ethereum.org)

TL;DR: 2026 disk sizes (Ethereum mainnet)

Geth full (snap‑synced + periodic prune): ~650–700 GB steady‑state; growth ~14 GB/week between prunes. (geth.ethereum.org)
Geth archive, path‑based (v1.16+): ≈1.9–2.0 TB for full history; no historical eth_getProof yet. (geth.ethereum.org)
Geth archive, hash‑based (legacy): typically >12 TB; many operators report 12–20+ TB. (geth.ethereum.org)
Erigon archive (Caplin): ~1.77 TB required (recommend 4 TB for headroom); full ≈920 GB; minimal ≈350 GB. (docs.erigon.tech)

Note: figures were last updated by client teams in September–November 2025 and will continue to grow; always plan ~1.5–2× headroom for operational safety. (docs.erigon.tech)

Deep dive: Geth archive in 2026 (path‑based vs hash‑based)

Two archive modes exist in Geth:

Path‑based archive (recommended for most teams)

Size: about 2 TB for full history on Ethereum mainnet. (geth.ethereum.org)
How it works: Geth keeps a single persisted state ~128 blocks behind the head plus “reverse diffs” for every block; these diffs are enough to answer historical state reads without storing full historical tries. (geth.ethereum.org)
Limitations: historical eth_getProof isn’t supported yet; latest ~128 blocks still offer proofs, but older blocks require the legacy (hash‑based) mode if proofs are mandatory. (geth.ethereum.org)
Practical placement: you can move historical state (“ancients”) to a cheaper device using --datadir.ancient. This lets you keep hot state on NVMe and colder history on cheaper SSD/HDD if latency is acceptable. (geth.ethereum.org)

Hash‑based archive (legacy, full Merkle tries)

Size: easily >12 TB on mainnet; advanced operators report database sizes in the tens of TB. (geth.ethereum.org)
Advantages: supports historical Merkle proofs for any block height. (geth.ethereum.org)
Trade‑offs: months to sync from genesis and high compaction overhead; SSD‑only in practice. Consider sharding history across nodes if you truly need this. (geth.ethereum.org)

Recommended flags (examples)

Full path‑based archive (index after full sync):

geth --syncmode=full --history.state=0
# after finishing full sync, enable indexing
geth --gcmode=archive --history.state=0

Notes: --history.state=0 retains all historical states; enabling --gcmode=archive after sync accelerates bootstrap; place history with --datadir.ancient=/mnt/history to isolate storage. (geth.ethereum.org)

When to choose which Geth archive:

If you require historical Merkle proofs for compliance or zero‑knowledge workflows, use hash‑based archive (budget 12–20+ TB and a long sync), or run a smaller hash‑based segment dedicated to the ranges you audit often. (geth.ethereum.org)
If you need fast historical state queries without proofs, choose path‑based archive (~2 TB) and scale horizontally under an RPC gateway. (geth.ethereum.org)

Deep dive: Erigon archive in 2026

Current measured sizes (Erigon 3 + Caplin)

Archive: 1.77 TB required; 4 TB recommended for headroom.
Full: ~920 GB.
Minimal (heavily pruned): ~350 GB. (docs.erigon.tech)

Why Erigon stays compact

Columnar, append‑friendly storage and “Caplin” re‑architecture keep history tight; the team publishes “datadir” sizes regularly. (docs.erigon.tech)
Modular RPC architecture (rpcdaemon) allows scaling read workloads independently of the core node. (docs.erigon.tech)

Operational tips

Pick prune.mode per need: archive, full, minimal, or blocks. You can also set prune distances to cap retained history. (docs.erigon.tech)
Put temp and snapshot directories on a separate disk to reduce contention; Erigon docs explicitly call out symlinking <datadir>/temp and <datadir>/snapshots. (docs.erigon.tech)
Hardware: for archive, 32–64 GB RAM and 4–8+ cores are suggested; use fast SSD/NVMe. (docs.erigon.tech)

Example commands

Archive:

erigon --prune.mode=archive

Full (default):

erigon --prune.mode=full

Minimal:

erigon --prune.mode=minimal

Reference: see Erigon 3 hardware and pruning documentation for exact knobs and current sizes. (docs.erigon.tech)

Geth full node in 2026: size and upkeep

Size: a snap‑synced full node is >650 GB; with default cache it grows about 14 GB/week. Pruning resets it back to ~650 GB. Plan your prune cadence (e.g., monthly on a 1 TB disk). (geth.ethereum.org)
State retention: full nodes keep recent block states only (about the last 128 blocks); older historical states are pruned and not directly queryable without archive. (geth.ethereum.org)
Prune guidance: run pruning before disks hit ~80% usage; have ≥40 GB free to start; expect many hours of downtime depending on hardware. (geth.ethereum.org)

Cost modeling (U.S. public cloud, January 2026)

You’ll mainly pay for block storage capacity, plus optional IOPS/throughput add‑ons for heavier RPC. On AWS EBS gp3 in a typical U.S. region:

Capacity: ~$0.08 per GB‑month.
Performance add‑ons: 3,000 IOPS and 125 MB/s included; extras cost $0.005 per IOPS‑month over 3,000 and ~$0.04 per MB/s‑month over 125 MB/s. (aws.amazon.com)

Approximate monthly storage costs (capacity only)

Geth full (1 TB volume): 1,024 GB × $0.08 ≈ $81.92/mo. (aws.amazon.com)
Erigon archive (2 TB volume): 2,048 GB × $0.08 ≈ $163.84/mo. (aws.amazon.com)
Geth archive, path‑based (2 TB): ≈ $163.84/mo. (aws.amazon.com)
Geth archive, hash‑based (12 TB): 12,288 GB × $0.08 ≈ $983.04/mo. (aws.amazon.com)

Performance headroom examples

Moderate read‑heavy RPC might provision 12k IOPS and 500 MB/s. On gp3, that’s +9,000 IOPS × $0.005 = $45/mo and +375 MB/s × $0.04 ≈ $15/mo, on top of capacity. (docs.aws.amazon.com)

Azure Premium SSD v2 has analogous “capacity + performance” pricing knobs (3,000 baseline IOPS included; up to 80k IOPS and 1,200+ MB/s on large volumes). Run a quick region‑specific calculator for apples‑to‑apples TCO. (learn.microsoft.com)

Which node fits your use case?

Choose Geth full if:
- You run validators and need a standards‑based EL with predictable upkeep and small footprint, and you don’t need historical states beyond ~128 blocks. Schedule offline pruning to maintain ≤1 TB. (geth.ethereum.org)
Choose Erigon archive if:
- You operate explorers, analytics, indexers, or L2 infra that need fast historical reads with a compact footprint (~1.8–2 TB), and you can live without historical Merkle proofs (Erigon focuses on state/history efficiency). (docs.erigon.tech)
Choose Geth archive (path‑based) if:
- You want an archive with ~Geth ergonomics and rich ecosystem support, but in ~2 TB instead of 12–20+ TB; you do not need historical eth_getProof in 2026. (geth.ethereum.org)
Choose Geth archive (hash‑based) only if:
- You absolutely require historical Merkle proofs or tools that traverse historical trie nodes; budget for 12–20+ TB and long initial syncs. (geth.ethereum.org)

Practical deployment patterns we see working in 2026

Split hot vs cold storage for Geth path‑based

Put the live state DB on a fast NVMe volume.
Place historical state (ancients) on a cheaper SSD (or even HDD if query latency tolerates it) via --datadir.ancient. This cuts NVMe spend without sacrificing correctness. (geth.ethereum.org)

Isolate Erigon temp/snapshots

Symlink <datadir>/temp and <datadir>/snapshots to a separate volume; this removes write bursts from the main DB device and reduces wear. (docs.erigon.tech)

Right‑size your gp3 add‑ons

Start with baseline 3,000 IOPS/125 MB/s. If RPC latency spikes under load, bump IOPS first, then throughput; both scale linearly with cost. (aws.amazon.com)

Plan headroom and pruning windows

For Geth full on a 1 TB disk, prune before 80% utilization and ensure ≥40 GB free prior to pruning. Consider a 2 TB disk to extend windows and reduce operator toil. (geth.ethereum.org)

Scale reads horizontally

Use multiple EL nodes (mix Erigon and Geth path‑archive) behind an RPC gateway. Pin archive‑only endpoints (e.g., historical state methods) to the archive pool.

Configuration snippets

Geth full (snap) with periodic prune:

geth --syncmode=snap
# Later, during maintenance window:
geth snapshot prune-state

Notes: prune only when fully synced and snapshot generation is idle; expect hours on busy disks. (geth.ethereum.org)

Geth archive (path‑based, full history):

# 1) Full sync from genesis (faster bootstrap)
geth --syncmode=full --history.state=0

# 2) Then enable archive indexing
geth --gcmode=archive --history.state=0
# Optional: move history to separate device
geth --datadir.ancient=/mnt/history

Caveat: historical eth_getProof is not yet available in this mode. (geth.ethereum.org)

Erigon archive:
```
erigon --prune.mode=archive
```
Current measured disk: ~1.77 TB required on Ethereum mainnet; 4 TB recommended. (docs.erigon.tech)

Emerging best practices for 2026

Avoid “blank check” archives: if you only need selected eras for auditing, use Geth path‑based with a finite --history.state and keep a dedicated hash‑based node for a narrow historical window where proofs are required. (geth.ethereum.org)
Separate concerns: run one Erigon archive for fast historical reads and at least one Geth full for mempool‑sensitive workflows; front them with a smart router that steers methods like eth_getStorageAt at old blocks to archive nodes. (docs.erigon.tech)
Control storage growth with SLAs: codify pruning windows (Geth full) and disk‑pressure alerts; on cloud, programmatically bump IOPS/throughput during indexing or catch‑up, then scale down. (geth.ethereum.org)

Quick buying guide (2026)

Minimal footprint, validator‑friendly: Geth full on a 1–2 TB NVMe; prune monthly or when ≥80% used. (geth.ethereum.org)
Cost‑efficient archive with fast reads: Erigon archive on a 2 TB NVMe (plus a small secondary volume for snapshots/temp). Expect ~1.8–2.2 TB usage over 2026. (docs.erigon.tech)
“Archive without the 12+ TB bill”: Geth archive (path‑based) on ~2 TB; verify your app doesn’t need historical eth_getProof. (geth.ethereum.org)
Full historical proofs or compliance: Geth archive (hash‑based) on 12–20+ TB, or segment history across multiple nodes. Expect higher TCO and long bootstrap. (geth.ethereum.org)

Bottom line

If you just need a reliable execution client for validators and most dApp backends, a Geth full node with disciplined pruning will keep you near ~650 GB and minimize costs. (geth.ethereum.org)
For historical data at production speed, Erigon archive remains the most storage‑efficient option around ~1.8–2.2 TB. (docs.erigon.tech)
If you want Geth’s ecosystem plus compact history, the 2025+ path‑based archive mode is a game‑changer at ~2 TB—just confirm your product doesn’t require historical Merkle proofs yet. (geth.ethereum.org)

If you’d like a tailored storage and cost plan (cloud vs on‑prem, expected query mix, growth modeling), 7Block Labs can benchmark your workloads across Geth full, Geth path‑archive, and Erigon archive, and ship a ready‑to‑run Terraform/Kubernetes stack with autoscaled RPC.