Geth vs Erigon vs Reth: Which Execution Client Should You Run?

So you've decided to run your own Ethereum node. Since The Merge, that means two programs: a consensus client (Lighthouse, Prysm, Teku, Nimbus, or Lodestar) and an execution client that holds the EVM state and answers your eth_* RPC calls. The consensus client choice is mostly preference. The execution client choice is the one that decides your disk bill, how long you wait to reach the tip, and whether debug_traceTransaction and historical eth_call are cheap or simply not an option.

There are three serious choices in 2026: Geth, Erigon, and Reth. They are not interchangeable. Picking the wrong one for your workload means either paying for terabytes you don't need or discovering — three days into a sync — that the node can't answer the queries you built around. Here's the honest breakdown.

What an execution client actually does

The execution client downloads blocks, re-executes every transaction to validate state transitions, stores the resulting state (account balances, contract storage, code), and exposes the JSON-RPC API your app talks to. Two terms decide most of the tradeoffs:

• Full node — keeps recent state (the last ~128 blocks of full state) plus all blocks and receipts. It can serve current balances, send transactions, and read logs. It cannot compute arbitrary historical state.
• Archive node — keeps every historical state root, so it can answer "what was this balance at block 12,000,000?" and run traces against old blocks. This is what powers debug_traceTransaction, historical eth_call, and most indexers. (If that distinction is fuzzy, see Full Node vs Archive Node.)

The headline difference between the three clients is how efficiently they store archive state — and that gap is enormous.

Geth — the default

Geth is the original Go client and still the most widely deployed. Its strengths are exactly what you'd expect from the reference implementation: the most battle-tested codebase, the broadest tooling and documentation (almost every tutorial assumes Geth), and fast snap sync for full nodes.

Modern Geth uses the path-based state scheme (PBSS), which dramatically cut its disk footprint versus the old hash-based scheme and made pruning far cleaner. A Geth full node lands around 1.2–1.5 TB and snap-syncs in roughly a day on NVMe.

Where Geth is weakest is archive. Even with PBSS, a Geth archive node is large and slow to build, and Geth's tracing throughput trails the other two. The other catch is a network-level one: Geth's majority share is a client-diversity risk for Ethereum — if a supermajority client has a consensus bug, it can finalize a bad chain. Running something else is a small contribution to network health.

Run Geth if: you want a full node for app reads and writes, you value the largest install base and the most documentation, and you don't need cheap archive.

Erigon — the archive specialist

Erigon (also Go) was built around a different idea: staged sync and a flat, deduplicated key-value layout that makes archive state shockingly compact. The headline is that Erigon serves a full archive node in roughly 2–3 TB — a fraction of legacy archive sizes — and it's the long-standing favorite for anyone running an indexer or doing heavy historical work.

Erigon 3 leaned further into this, making the efficient archive layout the standard path and improving sync ergonomics. The tradeoff is that Erigon is heavier on RAM and disk I/O during sync, and its staged-sync model behaves differently enough from Geth that some Geth-specific tooling assumptions don't carry over one-to-one.

Run Erigon if: you need archive state or high-volume traces and want the smallest possible archive disk bill. For most "I need historical state cheaply" cases, this is the answer.

Reth — the performance play

Reth is Paradigm's Rust client: modular, MIT/Apache-licensed, and designed for performance from the ground up. By 2026 it's production-ready and growing fast. It offers compact archive storage in the same ballpark as Erigon (~2.5–3 TB), strong tracing performance, and a clean, library-first architecture that's pleasant to build on top of.

Two things make Reth attractive beyond raw speed. First, it's a Rust codebase — a different language and team from the two Go clients, which is exactly what client diversity wants. Second, its modularity means parts of it get reused in rollup and indexing stacks, so the ecosystem around it is deep for a relatively young client.

The honest caveat: it's the newest of the three. It's well past "experimental," but it has the shortest production track record, so weigh that against your risk tolerance.

Run Reth if: you want top-tier performance and archive efficiency, you're comfortable on the newer (but solid) option, and you like contributing to client diversity.

Side by side

Disk figures are approximate for 2026 and move with chain growth and config (PBSS/pruning settings). Treat them as ranges, not promises.

So which one?

Strip away the detail and it's three clean buckets:

• Just need a working node for sending transactions and reading current state? Geth. It's the simplest path, and every guide you'll hit assumes it.
• Need archive or heavy tracing for an indexer, analytics, or historical eth_call? Erigon for the smallest disk bill, Reth if you want more performance and a Rust stack.
• Care about client diversity (you should, a little)? Run Erigon or Reth instead of adding to Geth's majority.

Whichever you pick, remember the part the client comparison hides: this is still a node you have to sync for a day-plus, keep patched through every hard fork, monitor around the clock, and run twice if you want real redundancy. And it's one chain. We did that full cost breakdown in Self-Hosted Node vs RPC Provider, and the math is sobering.

Or skip the decision entirely

The reason most teams don't agonize over Geth vs Erigon vs Reth is that they never run any of them. A managed Ethereum RPC endpoint gives you the synced result — current state, archive history, traces — without choosing a client, waiting on a sync, or babysitting the next fork. SwiftNodes runs the nodes; you get a flat-rate endpoint and point your app at it:

https://rpc.swiftnodes.io/rpc/eth?key=YOUR_API_KEY

If you genuinely want the control and learning of running your own, our run-a-node guide walks the full Geth + Lighthouse setup end to end. If you'd rather ship, grab a free key and skip straight to building.