Reth Explained: Reth vs Geth and Erigon for RPC, Archive and Tracing Workloads (2026)

Reth is Paradigm's Rust Ethereum client. In 2026 it is a production client at v2.10.1 (released 6 November 2026), it stores a full Ethereum archive in 2.31 TB where Geth's legacy archive passed 19 TB, and it serves the full debug_ and trace_ namespaces. Geth still runs on about half of the network's execution clients, has a dedicated log index that makes wide eth_getLogs queries 10 to 15 times faster, and has the longest production record. Which one should serve your RPC depends on whether your workload is tracing and archive reads, log scans, or plain state calls. Every figure below is dated and sourced at the end.

What Reth Is

Reth, short for Rust Ethereum, is an execution-layer client that pairs with any consensus client over the Engine API. Paradigm announced the alpha on 20 June 2023, declared 1.0 production-ready in June 2024 after a Sigma Prime audit, and shipped Reth 2.0 on 8 April 2026. The licence is Apache 2.0 and MIT, with no business-source restrictions.

Two design decisions explain most of what follows. Reth borrowed its architecture from Erigon: the staged sync pipeline, which downloads headers and bodies first and then runs execution, sender recovery and indexing as separate stages, and MDBX as the key-value store. Reth's README credits Erigon for both. Reth then moved the bulk of chain history out of the database into append-only "static files", which is why its archive is a fraction of Geth's: historical changesets are written once and never compacted.

Reth 2.0 made Storage V2 the default: hashed state in MDBX, changesets in static files, history indices in RocksDB. Paradigm reports a 20x speed-up in block persistence over V1. V1 nodes keep working and reth db migrate-v2 (v2.1.0, April 2026) converts them in place, but V1 support is scheduled for removal. Every component is also a library crate, which is why Base's base-reth-node, MegaETH's mega-reth and Circle's Arc client are all Reth builds with chain-specific code compiled in.

Reth in 2026: Versions and Status

Reth ships a minor release roughly every two to three weeks. The releases that matter for an operator reading this in November 2026:

OP-Reth, the OP Stack variant, is now maintained in the ethereum-optimism/optimism repository rather than under Paradigm, and since 2.0 the Reth README "actively recommends professional node operators to switch to Reth in production" for RPC, MEV, indexing and simulation.

Adoption is harder to measure. Ethernodes' peer crawl, as shown on clientdiversity.org on 9 November 2026, puts Geth at 50.13% of execution clients, Nethermind at 25.46%, Besu at 9.45%, Reth at 7.67% and Erigon at 6.53%; the validator survey on supermajority.info (Q4 2025 data) has Reth at 3%.

Archive Node Size and Sync Time: Reth vs Geth vs Erigon

Disk is where the three clients differ most, and where published numbers are least comparable: each client measures a different thing at a different block. The table puts vendor figures and Dwellir's fleet measurements side by side.

Three things to read out of that table.

A 2 to 2.5 TB archive is now the norm, not a Reth exclusive. Erigon has been there since Erigon 3, and Geth's path-based archive mode (v1.16.0, June 2025) reaches about 2 TB for flat state history. Until v1.17.0 (February 2026) that mode could not serve historical eth_getProof; it now can if you set --history.trienode=N, which is where Geth's 6.5 TB figure comes from. The 19 TB Geth archive that Etherscan charted until August 2024 is the legacy hash-based layout: still in the wild, still months to sync, no longer the number to plan on.

Fleet numbers run higher than vendor numbers, on every client. Dwellir's Erigon archive volumes hold 9.2 TB against Erigon's 2.25 TB datadir figure, and our two Reth archive nodes hold 3.8 TB and 9.9 TB against Reth's 2.31 TB. We measure everything on the volume, including the consensus client, logs and the operating system, and a node synced in 2024 on Storage V1 does not shrink itself; the 9.9 TB node is queued for migration. The self-hosted vs managed comparison explains the method.

Snapshots decide the sync time. Reth's portal served a 1.84 TB compressed archive download on 8 November 2026, Erigon's OtterSync pulls the same from torrents (hence a 14-hour archive figure that is mostly download), and Base's 3 hours from snapshot is the realistic planning number for a provider.

Tracing: debug_ and trace_ on Reth

Reth implements both tracing dialects natively: the Geth-style debug namespace (debug_traceTransaction, debug_traceCall, debug_traceCallMany, debug_traceBlock and variants, debug_executionWitness, debug_storageRangeAt) and the Parity-style trace namespace (trace_call, trace_callMany, trace_replayTransaction, trace_block, trace_filter, trace_transaction, plus Reth's own trace_transactionOpcodeGas and trace_blockOpcodeGas). Geth has never shipped the trace_ namespace; teams that wanted both on one node historically ran Erigon or Nethermind.

Three operating limits matter when a Reth node sits behind an RPC endpoint. On a full node (--full), every tracing method is limited to the last 10,064 blocks, about 33 hours of Ethereum; older traces need an archive node, which is Reth's default mode. trace_filter is capped at 100 blocks per request (--rpc.max-trace-filter-blocks). Concurrent tracing requests are bounded by --rpc.max-tracing-requests, derived from the core count because traces are CPU-bound, so a flood of debug_traceBlockByNumber calls queues instead of starving block processing.

Historical proofs are the surprise. --rpc.eth-proof-window defaults to 0, so eth_getProof at head minus 1 fails with "distance to target block exceeds maximum proof window" until the operator raises it (maximum 1,209,600 blocks). On an archive node the flag alone is enough; on a pruned node, widening the window cannot recover trie data the node never kept. Dwellir hit this when a customer asked for proofs on a Reth-based chain in September 2026; the fix was a 100,000-block window on that pool.

On raw speed there is no neutral RPC benchmark; the ethPandaOps Lab dashboard compares block validation, not RPC. Base reported block-building p99 falling from 2,319 ms on Geth to 698 ms on Reth in December 2024, and Chainstack markets its Reth nodes at "5x faster" debug and trace, a vendor claim. Dwellir's production guides for debug_traceTransaction, debug_traceCall and trace_filter cover request formats and timeouts that apply across clients.

eth_getLogs on Reth

This is the one workload where Geth is ahead, and the gap is structural. Geth has a dedicated log index. Reth does not: eth_getLogs walks every header in the range, tests the 2,048-bit bloom, and reads receipts for the blocks that match, with a 1 to 5% false-positive rate. The upstream issue that tracks a fix, paradigmxyz/reth#16999, quotes the benchmark that started it in June 2025: 0.55 seconds on Geth against 8.4 seconds on Reth for a 100,000-block query, and 22 seconds against 211 seconds for 2.5 million blocks. A FilterMaps index modelled on Geth's core/filtermaps is being built as an opt-in --filter-maps flag through an Ethereum Protocol Fellowship project, but as of 30 October 2026 it lived on a fork and had not merged.

Reth bounds the damage with two defaults: 100,000 blocks per filter request (--rpc.max-blocks-per-filter) and 20,000 logs per response (--rpc.max-logs-per-response). Exceeding either returns error -32602 with "query exceeds max block range" or "query exceeds max results, retry with the range a-b", so a client that reads the message can bisect. Dwellir allows a 10,000-block window per eth_getLogs call and counts it as one response; the eth_getLogs pricing post works through the cost per plan. For a year-long backfill of a popular token's transfers, the client decides whether each window takes one second or ten.

Execution Extensions

Execution Extensions, or ExEx, are the feature no other client has. An ExEx is a Rust future compiled into the Reth binary that receives a notification for every chain commit, revert and reorg, with the executed blocks and state changes attached, and reports back a FinishedHeight so that a pruned node never deletes data an extension has not consumed. Paradigm introduced them in May 2024 for indexers, bridges and rollup derivation pipelines that would otherwise poll an RPC. For a team that just needs an endpoint, an ExEx is nothing you call; it is how an operator builds a custom index at the node without a separate ETL pipeline.

Where Reth Fits as an RPC Backend, and Where Geth Still Wins

Geth keeps two advantages. It is the reference client for the OP Stack fault-proof program, so Base and Optimism run Geth full nodes for sequencing even after moving archive to Reth, and its log index is a measurable win. What Geth no longer has is a disk or sync-time advantage; the hash-based archive behind the "20 TB" line in older posts is no longer the mode its own docs recommend. The practical answer for an RPC operator is the one Base arrived at in December 2024: Reth for archive and tracing, Geth alongside it, and no single client in the path. Base credits that pairing with avoided outages when one client's compaction or misconfiguration took it out of service while the other kept answering.

How Dwellir Runs Reth

Dwellir announced Reth on the Ethereum endpoint in September 2024. Two years on, Ethereum mainnet runs behind a mix of execution clients: Erigon v3 archive pools (3.6.1 to 3.7.0 at the November 2026 measurement) and Reth 2.6.0 pools, with client-specific hostnames, api-ethereum-mainnet-erigon and api-ethereum-mainnet-reth, for teams that need one client's behaviour, and the default api-ethereum-mainnet in front. Reth variants also serve Base, Optimism, MegaETH, Arc and five more OP Stack chains.

In production that looks like a pruned Reth full node at 2.45 TB growing 1 to 2 GB a day, archive nodes between 3.8 and 9.9 TB, and 23 to 37 GB of resident memory per node with far more allocated, because MDBX relies on the page cache. A Storage V2 conversion on one of our smaller Reth chains in October 2026 took just over an hour plus about 28 minutes of offline rebuild.

Pricing does not change by client. One response is one credit, debug_ and trace_ are included on paid plans, eth_getLogs gets a 10,000-block window per call, and mainnet is served from archive nodes so calls at any past block work. Teams that want a Reth archive to themselves can take an Ethereum dedicated cluster at $12,600 a month with no rate limit, or an Unlimited Node from $119 a month. The method reference is at /docs/ethereum and the endpoint details at /networks/ethereum.

Conclusion

Reth closed the archive-size gap in 2024, the stability gap with 1.0 and 2.0, and in 2026 is the client Paradigm tells RPC operators to run. The 2.31 TB archive and native trace_ namespace make it the right backend for historical state and tracing, which is why Dwellir, Base and Chainstack all put it there. It trails Geth on wide eth_getLogs scans, where a log index is still unmerged, and on network share.

If your workload is traces and archive reads, test the Reth hostname against your heaviest debug_traceBlockByNumber and compare the p95 with your current provider. If it is a log backfill, measure one 10,000-block window on each client before you size the job. Create a free account to run both tests on Ethereum mainnet, or talk to the team about a dedicated Reth archive cluster.

Frequently Asked Questions

What is Reth?

Reth (Rust Ethereum) is an Ethereum execution client built by Paradigm and released under Apache and MIT licences. It borrows Erigon's staged sync and MDBX database, stores history in append-only static files, and exposes every component as a Rust library. Reth 1.0 shipped in June 2024 and Reth 2.0 in April 2026; the current release is v2.10.1 from 6 November 2026.

Is Reth better than Geth?

For archive, tracing and indexing workloads, Reth needs less disk and answers heavy calls faster: Reth measures its archive node at 2.31 TB on Storage V2 while Geth's hash-based archive passed 19 TB before Etherscan stopped charting it, and Base cut archive disk from 16.61 TB to 2.74 TB by switching. Geth still has the larger share of the network (about 50% of execution clients in Ethernodes' crawl, November 2026), a dedicated log index that makes wide eth_getLogs queries 10 to 15 times faster, and the longest production record. Most operators run both.

How big is a Reth archive node in 2026?

Reth's own measurement at block 24,396,823 is 2.31 TB for an archive node on Storage V2, 1.02 TB for a full node and 224 GB for a minimal node. The system requirements page asks for at least 2.8 TB of TLC NVMe. The compressed archive snapshot at snapshots.reth.rs was about 1.84 TB on 8 November 2026. Dwellir's two Reth archive nodes use 3.8 TB and 9.9 TB because they were synced at different times and one is mid-way through a Storage V2 migration, so plan for the drive, not the database.

Does Reth support debug_traceTransaction and trace_filter?

Yes. Reth implements the Geth-style debug namespace (debug_traceTransaction, debug_traceCall, debug_traceCallMany, debug_traceBlock and the raw block, header and receipt getters) and the Parity-style trace namespace (trace_call, trace_callMany, trace_replayTransaction, trace_block, trace_filter, trace_transaction and the opcode-gas variants). On a full node the tracing methods only work for the last 10,064 blocks; trace_filter is capped at 100 blocks per request by default; an archive node is needed for anything older.

Why is eth_getLogs slower on Reth than on Geth?

Reth has no dedicated log index. It scans every block header's bloom filter in the requested range and reads receipts where the bloom matches, so a wide range costs time in proportion to its width. The upstream issue tracking a log index (#16999, opened June 2025) quotes Geth at 0.55 seconds and Reth at 8.4 seconds for a 100,000-block query. A FilterMaps index for Reth is in development as an opt-in flag but had not merged as of 30 October 2026. Reth caps a request at 100,000 blocks and 20,000 logs by default; Dwellir allows 10,000 blocks per eth_getLogs call.

Sources

Reth, Geth and Erigon figures were read on 9 November 2026 unless a date is given. Dwellir fleet figures are Prometheus filesystem and memory metrics taken on 3 November 2026, as described in self-hosted vs managed RPC nodes.

• Reth: README, releases (v2.0.0 8 Apr 2026, v2.10.1 6 Nov 2026), Storage V2 disk savings, system requirements (as of 23 Jun 2025), pruning and node modes, debug namespace, trace namespace, reth node CLI reference, ExEx overview, snapshots.reth.rs (block 26,371,212, 8 Nov 2026), issue #16999
• Paradigm: Releasing Reth 2.0 (8 Apr 2026), Reth ExEx (May 2024)
• Geth: archive mode (edited 24 Feb 2026), hardware requirements, sync modes, releases (v1.17.0 17 Feb 2026, v1.17.10 23 Oct 2026), Etherscan archive chart (Geth series ends 19.05 TB at block 20,609,096, Aug 2024)
• Erigon: hardware requirements and sync times (measured 17 Sep 2026, page updated 20 Oct 2026), releases (v3.8.1 23 Oct 2026)
• Base: Scaling Base with Reth (18 Dec 2024)
• Client share: clientdiversity.org (Ethernodes and supermajority.info panels, 9 Nov 2026)
• Chainstack: Reth page (vendor performance claims)
• Dwellir: Ethereum network page, Ethereum docs, eth_getLogs pricing, hidden costs of archive nodes, Dwellir supports Reth (1 Sep 2024)