Nethermind has released version 2.0.0 of its Ethereum execution client, introducing a new Flat DB architecture that sharply reduces the storage required for archive infrastructure. A full Ethereum Mainnet archive using the new layout measured approximately 2.1 TB for the execution database and about 2.3 TB in total node storage, compared with the roughly 30 TB footprint highlighted by Nethermind for legacy archive configurations.
According to the official Nethermind 2.0.0 release notes, the September 22 release consolidates 669 merged pull requests and makes Flat DB the default state backend for new databases. The change affects how Nethermind stores and retrieves Ethereum state rather than modifying Ethereum’s protocol rules themselves. It arrives alongside continued Ethereum client development, including recent Erigon and Teku releases focused on execution and consensus-layer reliability.
Flat DB Changes the Archive Storage Model
Traditional archive configurations preserve historical Ethereum state at every block and can create substantial storage overhead. Nethermind 2.0 instead builds archive history directly on its flat-state database during ordinary synchronization. Operators can retain complete history, a rolling block window, history from a selected block onward, or deep history only for specified addresses. This allows RPC providers and data services to match storage costs more closely to the historical queries they actually need.
The headline 2.1 TB figure is a point-in-time measurement rather than a permanent hardware requirement. Nethermind measured Mainnet near block 25.88 million on September 1 and recommends provisioning roughly 3 TB for a full archive, including additional components and growth capacity. A windowed configuration retaining about two months of state and roughly one year of blocks measured around 926 GB for the execution database, although Nethermind describes that figure as provisional.
Performance gains are also workload-specific. In a 12-hour Mainnet benchmark, Flat DB processed blocks at 1.80x the throughput of the Nethermind 1.39.2 half-path baseline on 8-vCPU machines and 2.55x on 16-vCPU systems. Tail latency improved substantially, while eth_call benchmarks also showed higher throughput. However, initial synchronization took about 75% longer than the comparable 1.39.2 half-path configuration, underscoring that Flat DB does not accelerate every node operation.
Existing Nodes Do Not Migrate Automatically
The upgrade path requires attention from operators. Existing Patricia databases remain on Patricia when upgraded to Nethermind 2.0.0, meaning installing the new binary alone does not produce the reduced Flat DB archive footprint. Archive operators seeking the new layout must resync or use Nethermind’s supported trie-to-flat import process, while most ordinary nodes can upgrade in place without a full resynchronization.
Nethermind also lists breaking configuration changes and several known issues affecting fresh Flat DB deployments, making the release more consequential than a routine patch. That operational distinction resembles other recent Ethereum client updates where software availability and network-level activation remain separate events. Nethermind 2.0 provides new infrastructure capabilities immediately, but operators must deliberately adopt the Flat DB architecture to obtain its storage benefits.
The release is also prepared for Ethereum’s upcoming Glamsterdam fork on Sepolia, currently scheduled for October 6 at 13:53:36 UTC, while Hoodi and Mainnet timings remain unset. That aligns Nethermind with the broader Glamsterdam public-testnet roadmap. The next practical milestone is therefore adoption of Flat DB by production archive operators alongside successful Sepolia compatibility, which will show whether the measured storage and processing gains translate consistently across real-world infrastructure deployments.
