Geth vs Erigon vs Reth: Best Self-Hosted Ethereum Node Clients (2026)

Running your own Ethereum node gives you full control over your interaction with the blockchain. Instead of relying on third-party RPC providers like Infura or Alchemy, a self-hosted node lets you validate transactions independently, query chain data without rate limits, and contribute to the decentralization of the network.

In this guide, we compare three leading Ethereum execution layer clients: Geth (Go Ethereum), Erigon, and Reth (Rust Ethereum). Each takes a fundamentally different approach to storing and processing blockchain data, and choosing the right one depends on your hardware, use case, and performance requirements.

Comparison Overview

Geth (Go Ethereum): The Reference Client

Geth is the original Ethereum execution client, written in Go and maintained by the Ethereum Foundation. It is the reference implementation of the Ethereum protocol, meaning new EIPs and protocol changes are typically implemented here first.

Key Strengths

• Reference implementation: Geth defines the standard for Ethereum protocol behavior. If you want the most battle-tested, widely-used client, this is it.
• Largest network share: Historically, Geth runs on the majority of Ethereum nodes, giving it the most real-world testing and the largest community.
• Stable API: The JSON-RPC API is the de facto standard. Tools, libraries, and dApps are primarily tested against Geth.
• Light client support: Geth supports light client mode, which syncs only block headers and verifies data on demand, requiring minimal disk space.
• Extensive documentation: As the reference client, Geth has the most comprehensive documentation, tutorials, and community support.

Docker Deployment

Geth has an official Docker image on Docker Hub:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

services:
  geth:
    image: ethereum/client-go:latest
    volumes:
      - ./geth-data:/root/.ethereum
    ports:
      - "8545:8545"    # HTTP RPC
      - "8551:8551"    # Auth RPC (consensus layer)
      - "30303:30303"  # P2P
      - "30303:30303/udp"
    command: >
      --http --http.addr 0.0.0.0 --http.api eth,net,web3,txpool
      --authrpc.addr 0.0.0.0 --authrpc.port 8551
      --authrpc.vhosts "*" --authrpc.jwtsecret /root/.ethereum/jwtsecret
    restart: unless-stopped

For a quick start without persisting data (testing only):

1
2

docker run --rm -it -p 8545:8545 ethereum/client-go \
  --http --http.addr 0.0.0.0 --http.api eth,net,web3

Resource Requirements

A full Geth node requires approximately 1 TB of SSD storage and 16 GB of RAM for comfortable operation. Archive nodes need around 12 TB. Synchronization from genesis takes several hours on modern hardware.

Erigon: The Storage-Optimized Client

Erigon (formerly known as TurboGeth) is an Ethereum client built from the ground up with storage efficiency and sync speed as primary design goals. It uses a custom flat-file storage format instead of the traditional key-value database.

Key Strengths

• Dramatically reduced storage: Erigon’s custom storage format compresses historical data, reducing full node storage from ~1 TB (Geth) to ~800 GB, and archive storage from ~12 TB to ~2.5 TB.
• Faster synchronization: Erigon uses state snapshots and a staged sync process that downloads and processes data in parallel, significantly reducing initial sync time.
• Built-in pruning: Historical state data can be pruned automatically, keeping disk usage manageable without manual intervention.
• Rich RPC API: Erigon extends the standard JSON-RPC with additional methods for historical state access, trace debugging, and account history queries.
• Bornium snapshots: Pre-built snapshot files allow new nodes to start from a recent state without processing every block from genesis.

Docker Deployment

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

services:
  erigon:
    image: thorax/erigon:latest
    volumes:
      - ./erigon-data:/home/erigon/.local/share/erigon
    ports:
      - "8545:8545"
      - "8551:8551"
      - "30303:30303"
      - "30303:30303/udp"
    command: >
      --http --http.addr 0.0.0.0 --http.api eth,erigon,web3,net,debug,trace,txpool
      --authrpc.addr 0.0.0.0 --authrpc.port 8551
      --authrpc.vhosts "*" --authrpc.jwtsecret /home/erigon/.local/share/erigon/jwt.hex
    restart: unless-stopped

Resource Requirements

Erigon requires less disk space than Geth but benefits from high I/O throughput. An SSD is strongly recommended. Full node: ~800 GB, archive node: ~2.5 TB. RAM requirements are similar to Geth (16 GB recommended).

Reth (Rust Ethereum): The Performance-Focused Client

Reth is a modern Ethereum execution client written in Rust, developed by Paradigm and the broader Rust Ethereum community. It is designed for maximum performance, modularity, and developer experience.

Key Strengths

• Rust performance: Written in Rust with a focus on zero-cost abstractions, Reth delivers high throughput with predictable memory usage.
• Modular architecture: Reth’s design separates consensus, execution, and networking into independent modules, making it easier to customize and extend.
• Staged synchronization: Like Erigon, Reth downloads and processes blockchain data in stages (headers, bodies, receipts, state), enabling faster initial sync.
• Memory-mapped storage: Uses MDBX (a memory-mapped database) for efficient random access to blockchain data, balancing read performance with disk usage.
• Built-in tracing: Reth includes transaction tracing capabilities out of the box, useful for debugging and analytics.
• Active development: Backed by Paradigm (a major Ethereum research firm), Reth has a rapid development cycle with frequent releases.

Docker Deployment

Reth is published on GitHub Container Registry (GHCR):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

services:
  reth:
    image: ghcr.io/paradigmxyz/reth:latest
    volumes:
      - ./reth-data:/root/.local/share/reth
    ports:
      - "8545:8545"
      - "8551:8551"
      - "30303:30303"
      - "30303:30303/udp"
    command: >
      node --http --http.addr 0.0.0.0
      --authrpc.addr 0.0.0.0 --authrpc.port 8551
      --authrpc.jwtsecret /root/.local/share/reth/jwt.hex
      --datadir /root/.local/share/reth
    restart: unless-stopped

Resource Requirements

Reth’s full node requires approximately 700 GB of SSD storage. Archive mode is around 2.8 TB. The Rust implementation is generally more memory-efficient than Go-based clients, making 8-16 GB of RAM sufficient for most workloads.

Why Run Your Own Ethereum Node?

Running a self-hosted Ethereum node provides benefits that extend far beyond simple blockchain access.

Privacy and sovereignty: When you use a third-party RPC provider, that provider sees every address you query, every transaction you submit, and every smart contract you interact with. A self-hosted node keeps your blockchain activity private.

No rate limits or API keys: Public RPC endpoints impose rate limits and may require API keys with usage quotas. Your own node has no such restrictions, enabling heavy analytics workloads, historical data queries, and high-frequency trading bots.

Transaction reliability: During network congestion, public RPC providers may drop or delay your transactions. A direct node connection gives you the best chance of timely transaction inclusion.

Network health: Running a node contributes to Ethereum’s decentralization. The more independent nodes on the network, the more resilient it is against censorship and single points of failure.

Development and testing: If you build on Ethereum, having a local node gives you a reliable environment for testing smart contracts, debugging transactions, and querying historical state without external dependencies.

For broader decentralized infrastructure, see our decentralized storage guide and event sourcing comparison.

Quick Start: Which Client Should You Choose?

FAQ

Do I need to run a consensus layer client alongside the execution client?

Yes. Since Ethereum’s transition to proof-of-stake (the Merge), a full node requires both an execution layer client (Geth, Erigon, or Reth) and a consensus layer client (such as Prysm, Lighthouse, Teku, or Nimbus). The two clients communicate via the Engine API on port 8551 and require a shared JWT secret for authentication.

How much disk space do I need for an Ethereum full node?

Disk requirements vary by client. Geth requires approximately 1 TB for a full node, Erigon needs around 800 GB, and Reth requires roughly 700 GB. Archive nodes (which store the complete historical state) need 2.5 TB to 12 TB depending on the client. An SSD is strongly recommended for all configurations.

Can I run an Ethereum node on a Raspberry Pi?

Yes, but with limitations. A Raspberry Pi 4 or 5 with 8 GB of RAM and a fast external SSD can run a lightweight Ethereum node. However, sync times will be significantly longer, and the node may struggle during periods of high network activity. For production use, a dedicated server with NVMe storage is recommended.

What is the difference between a full node and an archive node?

A full node stores the current state of the blockchain and enough historical data to verify new blocks. An archive node stores the complete historical state of every account at every block, enabling queries like “what was the balance of address X at block Y?” Archive nodes are essential for block explorers and historical analytics but require significantly more disk space.

How long does it take to sync an Ethereum node from scratch?

Sync time depends on your internet speed, disk I/O, and client choice. With a fast SSD connection and 100+ Mbps internet: Geth takes several hours, Erigon and Reth can sync in 1-3 hours using their staged sync processes. Using state snapshots (Erigon’s Bornium snapshots) can reduce this further.

Are these clients free and open-source?

Yes. All three clients are fully open-source and free to use. Geth is licensed under LGPL-3.0, Erigon under LGPL-3.0, and Reth under Apache 2.0 / MIT dual license. You can use them for personal, commercial, or research purposes without any cost.

Can I switch between clients without re-syncing?

In most cases, yes. Execution clients store blockchain data in different formats, so you cannot directly share the data directory between clients. However, you can run a new client alongside an existing one, let it sync using peer-to-peer networking (which is faster than syncing from genesis), and then switch your applications to the new client once it is fully synced.