# Ethereum Client Database Overview ## Why This Matters Growing gas limits drive faster state growth, making the database layer a critical bottleneck. At 60M gas: ~124 GiB/year state growth; at 100M gas: ~197 GiB/year. Consequences include longer sync times, degraded access latency, and higher hardware requirements for node operators. ## Current Client DBs | Client | DB Engine | Approach | Roadmap | |--------|-----------|----------|---------| | Geth | Pebble | LSM-tree | [PBSS approach](https://geth.ethereum.org/docs/fundamentals/archive#how-it-works) - archive data offloaded to flat files | | Reth | MDBX | B-tree | **[triedb integration](https://github.com/paradigmxyz/reth/pull/20945)** + [RocksDB experiments](https://github.com/paradigmxyz/reth/pull/21620) | | Nethermind | RocksDB | LSM-tree | **[Paprika integration](https://github.com/NethermindEth/nethermind/pull/9853)** in progress | | Erigon | MDBX | B-tree | [Erigon 4](https://erigon.tech/big-release-and-renaming-of-erigon-2-2-2-3-into-erigon-3-4/) prototyping new state storage | | Besu | RocksDB | LSM-tree | Bonsai optimizations | | Ethrex | RocksDB | LSM-tree | - | ## Customised solutions Given that the snapshot is hard to optimize and well suited to a normal KV database, most solutions tackle optimizing storage for trie nodes. | Project | Links | Lang | License | Activity | Main Idea | Consensus Compatible | |---------|-------|------|---------|----------|-----------|----------------------| | triedb | [repo](https://github.com/base/triedb) | Rust | MIT | 🟢 | Trie-native disk layout, O(log N) lookups | ✅ | | Paprika | [repo](https://github.com/NethermindEth/Paprika) | C# | LGPL-3.0 | 🟡 | Patricia tree with separate Merkleization | ✅ | | MonadDb | [repo](https://github.com/category-labs/monad) | C++ | GPL-3.0 | 🟢 | Native Patricia Trie on disk, async I/O | ✅ Claims identical roots | | Carmen | [repo](https://github.com/0xsoniclabs/carmen) | Go | BSL-1.1 → LGPL 2028 | 🟡 | Flat storage with optional MPT schema | ⚠️ Sonic uses flat storage mode | | Firewood | [repo](https://github.com/ava-labs/firewood) | Rust | Ecosystem License | 🟢 | Trie-as-index, memory-mapped | ⚠️ Needs `ethhash`; license restricts to Avalanche | | SeiDb | [repo](https://github.com/sei-protocol/sei-chain) | Go | Apache-2.0 | 🟢 | AVL-tree with incremental roots | ❌ [Different state root](https://docs.sei.io/evm/differences-with-ethereum) | | QMDB | [repo](https://github.com/LayerZero-Labs/qmdb) | Rust | Apache-2.0 | 🔴 | Append-only with no in-place updates | ❌ No MPT support | Activity: 🟢 commits in last week | 🟡 commits in last 2 months | 🔴 stale/archived ## Benchmarks **Realistic state loads:** - [Bloatnet](https://cperezz.github.io/bloatnet-website/): Stress tests at 500GB, 1TB, 2TB+ state sizes, tracks client degradation at scale - [Ethpandaops Lab](https://lab.ethpandaops.io/ethereum/execution/timings): Measuring engine API timings on mainnet nodes **KV engine level:** - [goleveldb-bench](https://github.com/fjl/goleveldb-bench): Geth's LevelDB benchmarks - [Pebble benchmarks](https://hackmd.io/@jsvisa/geth-pebble-grant-report): Grant report comparing Pebble read/write performance **Gap:** No public benchmark for **state root computation** in isolation. Existing suites focus on opcode throughput or KV ops, not trie/DB performance. This is the key metric for evaluating custom DB solutions. ## Evaluation Criteria - Consensus compatible (identical state roots) - Block execution throughput at scale - State root computation latency - Sync performance with large state - License compatibility for client integration ## Next Steps - Talk to project teams and ask about their confidence in the idea - Define benchmark suite - Survey client teams on integration appetite
Last changed by  
 
Sina Mahmoodi
26

Read more

Project Proposal - Codename ClientBeat

Motivation The client ecosystem is different to how it was a few years ago. Today operators can choose between multiple high-quality clients, with new ones joining the ranks. Practical information about the clients exists but it is scattered across repos, websites, X threads and tribal memory. This makes it difficult for operators to make informed and use-case dependent decisions. Abstract We propose a dashboard which serves factual objective information about clients and surfaces the trade-offs that node operators care about, to help with the decision fatigue. Goals Help node operators choose the right client for their use-case

1/5/2026
Inside the Shadow-Geth Grant: A Personal Journey into Making Ethereum Faster

by jsvisaSeptember 2 2025 You can find the full report here: https://hackmd.io/@jsvisa/geth-pebble-grant-report Running a full Ethereum node has always appealed to me because it embodies the spirit of decentralization — you verify everything yourself and help secure the network. Go-Ethereum (Geth) is the most widely used execution client, so its performance determines how viable it is for everyday node runners, researchers, and infrastructure providers. This is my story as an external contributor funded by an Ethereum Foundation grant to work on PebbleDB performance, state size analysis, and code improvements. It was a rare chance to peek under the hood of Geth, experiment at massive scale, and push forward the limits of what the client can do. Why Benchmark and Analyse Geth? The grant’s aim was simple: measure where Geth struggles with very large databases and fix it. Over time the Ethereum state has ballooned as more contracts, tokens and users join the network. By the start of 2025 the database was hundreds of gigabytes and projected to keep growing at ~48 GiB per year. Rather than rely on gut feelings, I wanted concrete data, so the project was split into four phases:

9/3/2025
Client Summit

Invitees: ELs (incl. ethrex) CLs Etherscan Infura Alchemy Ankr Tenderly Quicknode

8/28/2025
Workflow A: Head-of-Chain Execution & Tracing — Replica Plan

Goal: Serve eth_call / tracing at the tip (and most recent 128 blocks), without running more full nodes and easy spin-up of new instances (i.e. Workflow A). Model: Captain → Followers Captain: one live writer. Followers: read-only replicas serving RPC, fed by captain snapshots + state diffs. Architecture (high-level) Base snapshot of state at block S (exported every 3–4 hours). State diffs from S → H applied by followers to "sync".

7/30/2025
Read more from Sina Mahmoodi
Published on HackMD