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

---

What changed since 2024-2025

• Geth has rolled out a new archive mode that works a bit differently--it's path-based and stores historical state as reverse diffs. This smart change slashes the storage needs from several tens of TB (the old hash-based method) down to a much more manageable 1.9-2.0 TB on the mainnet. Just a heads up, though: if you need historical Merkle proofs (like with eth_getProof), this mode doesn't support them yet. Check it out here: (geth.ethereum.org)
• Erigon 3, also known as “Caplin” storage, has finally stabilized its storage profile and now provides up-to-date, accurate disk usage stats. For the mainnet archive, you’re looking at around 1.77 TB, with full storage at about 920 GB and minimal storage around 350 GB (these numbers are from late 2025). Dive into more details here: (docs.erigon.tech)
• If you’re running Geth full nodes, they tend to hover around >650 GB when snap-synced and pruned. With the default cache, you can expect about a 14 GB growth per week until you decide to do an offline prune, so it’s a good idea to plan for some extra space or set up a pruning schedule. More info can be found here: (geth.ethereum.org)

---

TL;DR: 2026 disk sizes (Ethereum mainnet)

• Geth full (snap-synced + periodic prune): You’re looking at about 650-700 GB in steady-state, with an increase of around 14 GB per week between prunes. Learn more here.
• Geth archive, path-based (v1.16+): For the full history, you need roughly 1.9-2.0 TB; just a heads up, historical eth_getProof isn’t available yet. Check it out.
• Geth archive, hash-based (legacy): Typically, you’ll need more than 12 TB for this one; many users are seeing between 12 and 20+ TB. More details here.
• Erigon archive (Caplin): Plan for about 1.77 TB, but it’s a good idea to have around 4 TB to be safe; the full setup runs around 920 GB, and the minimal setup is about 350 GB. More info available here.

Note: The numbers were last refreshed by the client teams between September and November 2025, and they’re expected to keep increasing. Always account for about 1.5 to 2 times the headroom for operational safety. (docs.erigon.tech)

---

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

Two Archive Modes in Geth

Geth offers two distinct archive modes:

1) Path‑based Archive (Great for Most Teams)

• Size: Roughly 2 TB if you want the full history on the Ethereum mainnet. (geth.ethereum.org)
• How it Works: Geth maintains a single persisted state that's about 128 blocks behind the current block, along with “reverse diffs” for every block. This setup is clever because it allows for historical state reads without needing to store the entire historical tries. (geth.ethereum.org)
• Limitations: Just a heads up--historical eth_getProof isn’t supported at the moment. While the latest ~128 blocks do provide proofs, for older blocks, you’ll need to switch to the legacy (hash‑based) mode if you really need those proofs. (geth.ethereum.org)
• Practical Placement: You have the option to move your historical state (“ancients”) onto a more affordable device using --datadir.ancient. This way, you can keep your hot state on NVMe drives while stashing away the colder history on cheaper SSDs or HDDs, as long as that latency works for you. (geth.ethereum.org)

2) Hash‑based Archive (Legacy, Full Merkle Tries)

• Size: We’re talking about more than 12 TB on the mainnet! Some advanced operators have even reported database sizes soaring into the tens of TB. (geth.ethereum.org)
• Advantages: One of the cool perks here is that it supports historical Merkle proofs for any block height. That’s pretty handy! (geth.ethereum.org)
• Trade‑offs: Just a heads up, syncing from genesis can take months, and there's a hefty compaction overhead. So realistically, it’s SSD-only. If you really need this setup, you might want to think about sharding history across different nodes. (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:

• Using --history.state=0 keeps all historical states.
• If you enable --gcmode=archive after syncing, it speeds up the bootstrap process.
• Place your history using --datadir.ancient=/mnt/history to keep your storage separate.

For more details, check out the official Geth documentation.

When to Choose Which Geth Archive

• If you're looking for historical Merkle proofs for compliance or zero-knowledge workflows, go for the hash-based archive. Just a heads up, you’ll need to budget around 12-20+ TB and expect a lengthy sync time. Alternatively, you could set up a smaller hash-based segment that focuses on the ranges you audit the most. (geth.ethereum.org)
• On the other hand, if you want quick historical state queries without the need for proofs, the path-based archive is your best bet. This one’s about 2 TB and allows for horizontal scaling under an RPC gateway. (geth.ethereum.org)

---

Deep dive: Erigon archive in 2026

Current Measured Sizes (Erigon 3 + Caplin)

• Archive: You'll need about 1.77 TB, but it's a good idea to have 4 TB set aside for some extra space.
• Full: Approximately 920 GB.
• Minimal (heavily pruned): Roughly 350 GB. Check out the details over at docs.erigon.tech.

Why Erigon Stays Compact

• With its columnar, append-friendly storage and the clever "Caplin" re-architecture, Erigon keeps its history nice and tight. The team also regularly shares updates on "datadir" sizes, so you can always stay in the loop. Check it out here!
• Thanks to a modular RPC architecture (rpcdaemon), Erigon lets you scale read workloads separately from the core node. This way, you can optimize performance without any fuss. For more details, head over here.

Operational Tips

• Choose the right prune.mode for your needs: you can go with archive, full, minimal, or blocks. Plus, don't forget to set prune distances to keep your retained history in check. Check out the details here.
• To minimize contention, it’s a good idea to put your temp and snapshot directories on a separate disk. Erigon docs even recommend using symlinks for /temp and /snapshots. Find more info here.
• As for hardware, if you’re going for archive mode, aim for 32-64 GB of RAM and at least 4-8 cores. And don’t skimp on speed--using fast SSDs or NVMe is highly recommended. For specifics, take a look here.

Example commands

• Archive:

  erigon --prune.mode=archive

• Full (default):

  erigon --prune.mode=full

• Minimal:

  erigon --prune.mode=minimal

For the specific settings and current sizes, check out the Erigon 3 hardware and pruning documentation. You can find it here: (docs.erigon.tech).

---

Geth full node in 2026: size and upkeep

• Size: If you're running a snap-synced full node, be ready for it to take up more than 650 GB. With the default cache settings, it tends to grow by around 14 GB each week. Pruning helps you reset it back down to roughly 650 GB. It's a good idea to plan out your pruning schedule--maybe monthly if you've got a 1 TB disk. (geth.ethereum.org)
• State retention: Full nodes only keep track of recent block states, about the last 128 blocks. Anything older gets pruned away and isn’t easily accessible unless you’re using an archive node. (geth.ethereum.org)
• Prune guidance: It's best to start pruning before your disk usage hits around 80%. Aim to have at least 40 GB free to kick things off, and be prepared for a potential downtime that can last several hours, depending on your hardware. (geth.ethereum.org)

---

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

You’ll mostly be covering the cost for block storage capacity, and if you need some extra muscle for IOPS or throughput, you can add those on for more intense RPC tasks. Here’s what it looks like with AWS EBS gp3 in a standard U.S. region:

• Capacity: Around $0.08 for every GB per month.
• Performance add-ons: You get 3,000 IOPS and 125 MB/s to start; if you need more, it’s an extra $0.005 for each additional IOPS per month over 3,000 and about $0.04 for each extra MB/s per 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/month. (aws.amazon.com)
• Erigon Archive (2 TB Volume): 2,048 GB × $0.08 ≈ $163.84/month. (aws.amazon.com)
• Geth Archive, Path‑Based (2 TB): ≈ $163.84/month. (aws.amazon.com)
• Geth Archive, Hash‑Based (12 TB): 12,288 GB × $0.08 ≈ $983.04/month. (aws.amazon.com)

Performance Headroom Examples

• If you're dealing with a moderate read-heavy RPC, you might set up around 12k IOPS and 500 MB/s. For gp3, that breaks down to an extra +9,000 IOPS, which costs you about $45 per month ($0.005 per IOPS), and an additional +375 MB/s will run you around $15 per month ($0.04 per MB/s), all on top of your storage capacity. You can check out more details on this over at the AWS documentation.

Azure Premium SSD v2 offers similar pricing options based on both capacity and performance. You get 3,000 baseline IOPS, and it can boost up to 80k IOPS with speeds exceeding 1,200 MB/s, especially on larger volumes. If you're curious about the total cost of ownership (TCO) in your area, check out the region-specific calculator for a side-by-side comparison. (learn.microsoft.com)

---

Which node fits your use case?

• Go with Geth full if you:
  • Are running validators and want a standards-based execution layer that’s easy to maintain and doesn’t take up too much space. You’re fine with not having historical states beyond about 128 blocks. Just set up some offline pruning to keep it under 1 TB. (geth.ethereum.org)
• Go with Erigon archive if:
  • You’re running explorers, doing analytics, working with indexers, or managing L2 infrastructure that requires speedy historical reads while keeping a smaller footprint (around 1.8-2 TB). Just be okay with not having historical Merkle proofs, since Erigon takes a more efficient approach to state and history. (docs.erigon.tech)
• Go for Geth archive (path‑based) if:
  • You're looking for an archive that has the familiar Geth feel and great ecosystem support, but you want to keep it around ~2 TB instead of the hefty 12-20+ TB. Plus, you won't be needing historical eth_getProof in 2026. (geth.ethereum.org)
• Pick Geth archive (hash‑based) only if:
  • You really need historical Merkle proofs or any tools that navigate through historical trie nodes. Make sure you’re ready for 12-20+ TB of storage and some lengthy initial sync times. (geth.ethereum.org)

---

Practical deployment patterns we see working in 2026

1. Hot vs Cold Storage for Geth Path-Based

• Keep your live state database on a speedy NVMe drive.
• Store historical state (ancients) on a more affordable SSD or even an HDD if you're okay with some extra query latency by using the --datadir.ancient option. This way, you can save on NVMe costs without losing any accuracy. (geth.ethereum.org)

1. Isolate Erigon temp/snapshots

• Create symlinks for /temp and /snapshots to point to a different volume. This helps keep those write bursts away from your main DB device, which can really cut down on wear and tear. Check out the details in the Erigon documentation.

1. Optimize your gp3 add-ons

• Begin with the baseline of 3,000 IOPS and 125 MB/s. If you notice RPC latency increasing when under load, try increasing IOPS first, then look at boosting throughput. The great thing is that both of these scale linearly with your costs! (aws.amazon.com)

4) Plan Headroom and Pruning Windows

• If you’re running Geth on a 1 TB disk, make sure to prune when you hit around 80% usage. You’ll want to keep at least 40 GB free before doing any pruning. If you want to make your life easier and have less hassle, think about upgrading to a 2 TB disk. It’ll help you extend those windows and cut down on the maintenance work. (geth.ethereum.org)

1. Scale Reads Horizontally

• Set up several EL nodes by mixing Erigon and Geth path-archive behind an RPC gateway. Make sure to pin your archive-only endpoints (like those historical state methods) to the archive pool.

---

Configuration snippets

• Geth full (snap) with periodic pruning:

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

  Notes: Only prune when your sync is complete and snapshot generation isn’t active. If you’re working with busy disks, be ready to wait for several hours. (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: Right now, historical eth_getProof isn’t available in this mode. You can check out more details here.

• Erigon Archive:

  erigon --prune.mode=archive

  As of now, the current measured disk space on the Ethereum mainnet is about 1.77 TB, but it's a good idea to aim for around 4 TB for optimal performance. Check out more details here.

---

Emerging best practices for 2026

• Steer clear of “blank check” archives: If you’re just auditing certain time periods, go with Geth using a path-based approach with a specific --history.state. It’s a good idea to have a separate hash-based node for a limited historical range when you need proofs. (geth.ethereum.org)
• Split your tasks: Set up one Erigon archive for quick historical reads and at least one Geth full node for those mempool-sensitive tasks. Use a smart router to direct calls like eth_getStorageAt for older blocks to the archive nodes. (docs.erigon.tech)
• Keep an eye on storage growth with SLAs: Define your pruning windows (for Geth full) and set up disk-pressure alerts. If you’re running on the cloud, automatically increase IOPS/throughput during indexing or catch-up periods, then scale it back down when you don’t need it. (geth.ethereum.org)

---

Quick buying guide (2026)

• Minimal footprint, validator-friendly: You can run a Geth full node on a 1-2 TB NVMe drive. Just remember to prune it monthly or whenever you hit that 80% mark! (geth.ethereum.org)
• Cost-efficient archive with fast reads: Think about setting up an Erigon archive on a 2 TB NVMe. You’ll also want a little extra storage for snapshots or temporary files. Keep in mind, you'll probably see around 1.8-2.2 TB in usage by 2026. (docs.erigon.tech)
• “Archive without the 12+ TB bill”: If you’re considering a Geth archive, a path-based option on roughly 2 TB should do the trick. Just double-check that your app doesn’t require historical eth_getProof! (geth.ethereum.org)
• Full historical proofs or compliance: For a solid Geth archive that’s hash-based, you’re looking at 12-20+ TB. You might even want to break up the history across multiple nodes. Be prepared for a higher total cost of ownership and a longer setup time. (geth.ethereum.org)

---

Bottom line

• If you're on the lookout for a solid execution client for validators and most dApp backends, a Geth full node with smart pruning is a great choice. It'll keep your storage around ~650 GB and help you save on costs. (geth.ethereum.org)
• For those who need historical data at lightning speed, the Erigon archive is still the best bet for storage efficiency, coming in at about ~1.8-2.2 TB. (docs.erigon.tech)
• Want Geth’s ecosystem but with a compact history? The 2025+ path-based archive mode is a total game-changer, sitting at around ~2 TB--just make sure your project doesn’t need historical Merkle proofs yet. (geth.ethereum.org)

If you're looking for a custom storage and cost plan--whether it's cloud versus on-prem, expected query mix, or growth modeling--7Block Labs has got you covered. We can evaluate your workloads on Geth full, Geth path-archive, and Erigon archive. Plus, we’ll deliver a ready-to-deploy Terraform/Kubernetes stack that includes autoscaled RPC.