Ethereum execution client hardware footprint, measured

How much machine does an Ethereum execution client need once it sits at the tip of mainnet? Our fleet runs every major execution client on its own host, all with 12 cores, five of six client sets with 16 GiB RAM, one consensus client per pairing on a separate machine. Same chain, same engine-API traffic, one telemetry pipeline. Averaged over the same 36 hours, the synced clients hold between 4.9 and 15.6 GiB of host memory, burn about half a CPU core, and write to disk at anywhere from 0.9 to 22 MB/s. The spread is the story: the client you pick decides whether your box idles or works.

Read this first

• Validator-client traffic is mirrored, not live. During this window, every consensus client received a copy of the requests our validator clients send to production nodes. Each pairing therefore carries the request load of a staking node, including the duty-driven engine-API work that reaches the execution client; no keys live on this fleet and nothing signs from it.
• Reth's row is from an earlier synced version. The Reth version on our hosts during the June window was mid-resync, so its numbers come from v1.11.3, the last time Reth fully synced on this fleet (four days ending 2026-04-23). It is labeled wherever it appears; the other five are the June window.
• Ethrex runs on 64 GiB hosts. Its working set does not fit the 16 GiB envelope the other five live in. Details below.
• One window, young hosts. All numbers are 36-hour averages ending 2026-06-11 ~15:00 UTC; host uptimes were 2 to 8 days. Treat them as a snapshot of these versions, not eternal constants.

The fleet, and what we measured

Each execution client runs six times, once per consensus-client partner (Prysm, Lighthouse, Teku, Nimbus, Lodestar, Grandine, all supernodes on their own hosts; Fusaka's hardware impact is a separate post). The EC host runs the execution client, a node exporter, and a log shipper, nothing else. So host-level telemetry is, to a close approximation, the execution client's footprint, measured the same way for all six clients. Per-client numbers below average across the six pairings.

Versions in the June window: Geth v1.17.3, Nethermind 1.38.0, Besu 26.6.0, Erigon v3.4.3, Ethrex 15.0.0. Sync state was verified from container logs, not just metrics; all five were importing blocks at the live tip (block ~25,294,900) during the window. Reth ran v2.2.0 then but was mid-resync, so its row is taken from v1.11.3 in April, the last time it was synced on this fleet (see below).

Client	RAM avg	RAM peak	CPU avg	Busiest 30 min	Disk read	Disk write	P2P rx / tx
Nethermind	4.9 GiB	6.2 GiB	0.53 cores	0.78 cores	1.4 MB/s	1.1 MB/s	0.30 / 0.30 MB/s
Besu	5.6 GiB	9.7 GiB	0.44 cores	2.15 cores	3.0 MB/s	1.5 MB/s	0.14 / 0.09 MB/s
Erigon	6.0 GiB	13.6 GiB	0.45 cores	2.86 cores	8.1 MB/s	22.7 MB/s	0.24 / 0.24 MB/s
Geth	7.9 GiB	8.4 GiB	0.48 cores	1.15 cores	0.9 MB/s	0.9 MB/s	0.33 / 0.68 MB/s
Reth (v1.11.3, see note)	8.5 GiB	12.7 GiB	0.42 cores	0.94 cores	2.0 MB/s	4.0 MB/s	0.36 / 0.52 MB/s
Ethrex (64 GiB host)	15.6 GiB	17.6 GiB	0.55 cores	1.09 cores	1.0 MB/s	1.1 MB/s	0.82 / 0.74 MB/s

RAM is host memory in use (total minus available). Throughput values are decimal MB/s. CPU is in cores of the 12 each host has. P2P traffic is the host's public interface; the internal interface (engine API, monitoring) is excluded. Reth note: the version on our hosts during the June window was mid-resync, so Reth is measured over four days ending 2026-04-23, its last fully-synced window on this fleet, running v1.11.3. The chain head was about 0.4M blocks lower then, so read Reth as same-regime, not same-day. More below.

RAM: 5 to 16 GiB, and one client out of envelope

Five of the six fit a 16 GiB host. Nethermind is the lightest at 4.9 GiB average, Geth the steadiest heavyweight at 7.9 GiB with a peak only half a GiB above its average, and Reth sits just above it at 8.5 GiB. The peak column is where sizing decisions live: Besu spikes to 9.7 GiB, Reth to 12.7, and Erigon's commit and prune cycles push the host to 13.6 GiB. On 16 GiB that still works, but those three leave the least slack.

Ethrex does not fit. Its process alone held 15.3 GiB resident, more than the usable RAM of the 16 GiB hosts the other five run on, so its set lives on 64 GiB machines where it averaged 15.6 GiB and peaked at 17.6 GiB. No judgement attached: it is the youngest client of the six and the same fleet measured it executing blocks in 66 ms at the tip. But if you plan an Ethrex node today, plan more than 16 GiB.

The consensus partner barely matters for the established clients: across the six pairings, per-pairing RAM varies by one to four percent for Geth, Nethermind, Besu and Erigon. Ethrex moves more, 15.7 to 19.1 GiB depending on the partner over a 7-day view.

The RSS trap

If you put these six clients on one RSS dashboard, Erigon looks like it is about to die: its process reports 12.9 GiB resident on a host whose memory in use is 6.0 GiB. Both numbers are correct. Erigon (and Reth) serve state from memory-mapped files, and resident set size counts every mapped page currently in RAM, almost all of which the kernel can reclaim on demand. Ethrex's 15.3 GiB RSS, by contrast, sits within a few hundred MiB of its host's missing memory: that allocation is anonymous and cannot be reclaimed.

Same metric name, opposite meanings. Alert on host available memory, not on the client process RSS, or an mmap-based client will page you forever while a genuinely full host stays quiet. The rest of each 16 GiB box fills with page cache (7 to 10 GiB here), which is the system working as intended, not a leak. We hit the same class of problem with disk metrics in the pruning census and with a heap that did lie in the Besu case study.

CPU: half a core at the tip

Every synced client averaged between 0.42 and 0.55 of one core. Twelve cores sit mostly idle once a node follows the chain; the busiest half-hour of any client was Erigon's 2.86 cores. CPU is a sync-time resource, and Reth shows both sides of it: 0.42 cores synced, against the 1.22 cores its hosts pull right now while they resync the chain. If you size a machine for an execution client, you buy cores for the initial sync and for recovery after downtime, not for steady state. Our sync-speed census measures that phase client by client.

Disk I/O: where the spread gets serious

This is the widest spread in the census, and it is architectural. Geth keeps its working state in those 7.9 GiB of RAM and touches disk at under 1 MB/s in each direction, the quietest profile of the six. Nethermind, Besu, Ethrex and Reth stay in the low single digits (Reth at 2.0 read, 4.0 write). Erigon inverts the picture: its layered domain files and continuous background pruning write a sustained 22.7 MB/s, about 1.9 TB per day, plus 8 MB/s of reads, in exchange for the smallest disk footprint of the fleet (519 GB vs Geth's 1,731 GB).

That write rate is a budget item. A consumer 2 TB NVMe rated for 1,200 TBW reaches its endurance rating in roughly 20 months of Erigon steady state, before counting the initial sync. Enterprise drives shrug at it, but on hobbyist hardware the cheapest-disk client is also the one that consumes disks fastest. Disk capacity itself is the other axis, and we covered it in depth in the pruning post; current footprints run Erigon 519 GB, Ethrex 588 GB, Nethermind 1,222 GB, Besu 1,265 GB and Geth 1,731 GB, with synced Reth (v1.11.3, April) around 1,399 GB.

Network: a home connection is plenty

P2P traffic, measured at the host's public interface, stays under 2 MB/s combined for every client. Ethrex moves the most (0.82 MB/s down, 0.74 up, about 4 TB per month both directions combined), Geth uploads the most of the rest (0.68 MB/s, serving peers from its long-lived position in the network), Besu is the quietest at about 0.6 TB per month, with Reth's April figures landing in the middle near 2 TB. On an uncapped line none of this matters; on a metered connection the gap between 0.6 and 4 TB per month picks your client for you. Two notes on reading these numbers: the interface sees discovery chatter, transport overhead and peers that never complete a handshake, so it reads higher than a client's own P2P accounting (Geth's internal counters claim roughly half of what its interface carries), and how each client builds the peer set behind this traffic is covered in the peering deep dive.

Reth, and why its row is dated differently

Reth's row needs the asterisk because the version on our hosts during the June window was not following the tip. It has been resyncing across two releases (v2.1.0, then v2.2.0) since late April, and another deploy lands today, which resets the back-fill again. So rather than print back-fill load as if it were steady state, we took Reth's numbers from the last window it was demonstrably synced: four days ending 2026-04-23, on v1.11.3, with forkchoiceUpdated answered VALID and the pipeline's finish stage tracking the head block for block. Whether the v2.x line stays behind because of the client or our own deploy cadence is a separate question we have not closed, so we make no claim about it here.

Synced, Reth is unremarkable in the best way: 8.5 GiB average RAM, half a core, 2 MB/s of reads and 4 of writes. That is close to Geth on memory and well under Erigon on disk, which corrects something we expected going in, that Reth's mmap-heavy design would write like Erigon. It does not.

The current back-fill is also a clean illustration of two things this series keeps returning to. First, the cost of syncing: the same hosts that sip 0.42 cores when synced pull 1.22 cores and sustain 22 MB/s reads and 23 MB/s writes while catching up. Second, why we read logs and not just dashboards. Checking the resync this week, Reth's stage checkpoints had all jumped to 25236949 and a metrics panel would have called it done, but the logs showed only execution, hashing and merkle finished, with the final transaction-lookup and history-index stages still grinding at checkpoint=0, about 93,000 blocks behind the tip, every live payload answered SYNCING. We will refresh all six clients on a single window once the new Reth follows the tip again.

Sizing takeaways

Condensed into hardware requirements for a mainnet execution client in mid-2026:

• 16 GiB RAM fits five of six clients with room to spare; Nethermind and Besu leave the most headroom, Erigon the least. Ethrex currently needs more.
• Cores are for syncing. Half a core follows mainnet; buy 8+ for the day you resync.
• Watch TBW, not just GB. Erigon saves you a terabyte of capacity and spends your drive's write endurance for it. Geth does the opposite.
• Bandwidth is a non-issue unless your line is metered; then 0.6 to 4 TB per month separates the clients.
• Alert on host available memory. Process RSS lies for mmap-based clients.

That table at the top is what StereumLabs AI works with on our fleet: identical hosts, one variable, every client pairing observed the same way. This post shows that comparison under the conditions the fleet happened to be in, which is not fully like-for-like: Reth's row comes from an earlier window and the hosts were freshly rebuilt. Lining the clients up on truly equal footing means choosing comparable periods out of a history with uneven data quality and consistency, which is an analysis in its own right, not a lookup on a static panel. That is what StereumLabs AI is built for, and it is how we pinned Reth's last synced window for this post. When one node stops matching its siblings, that divergence is a finding, sometimes an upstream bug report. If you run Ethereum infrastructure and want this lens on your own nodes, reach us at stereumlabs.com or contact@stereumlabs.com.

Methodology

Numbers come from node_exporter on the dedicated EC hosts of our NDC2 deployment (Vienna), queried on the Prometheus-cold datasource (uid aez9ck4wz05q8e), with the fleet labels documented in build your own dashboards. Per-client values average the six CC pairings (avg by (ec_client)); a second Geth set on GCP was excluded as a different platform.

• Window: 36 hours ending 2026-06-11 ~15:00 UTC, e.g. avg_over_time((node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes)[36h:30m]). We chose 36 h over our usual 7 d because most EC hosts were rebooted 2.2 days earlier; counter resets at the reboot depress 7-day increase() figures (Erigon's write rate reads 12 MB/s over 7 d but holds 19 to 23 MB/s in every post-reboot hour).
• Reth's window: four days ending 2026-04-23, the last period Reth was synced on this fleet (v1.11.3), measured the same way and averaged across the same six pairings. Confirmed synced by forkchoiceUpdated answered VALID with zero SYNCING and the pipeline finish stage advancing one block per slot; the v2.1.0 then v2.2.0 line deployed since has answered SYNCING continuously. Chain head was ~24.94M then against ~25.29M for the June five.
• RAM is MemTotal - MemAvailable in GiB; peaks are max_over_time over the same window. Process RSS via process_resident_memory_bytes where clients expose it (Besu, Ethrex, Erigon).
• CPU from increase(node_cpu_seconds_total{mode!="idle"}[36h]) per host; the busiest-half-hour figure is the max of 30-minute rates.
• Disk from node_disk_read_bytes_total / node_disk_written_bytes_total on the data device. Network from node_network_*_bytes_total on the host's public P2P interface only; each host's second, internal interface (engine API from the CC host, Prometheus scrapes, log shipping) is excluded. We cross-checked the interface assignment against Geth's and Nethermind's own P2P byte counters: the host interface reads higher than client-internal accounting because discovery, failed handshakes and transport overhead never reach the client's counter, and we report the host number because it is what your line carries. Binary byte values converted to decimal MB/s.
• Hardware: every EC host has 12 cores; 16 GiB RAM except the Ethrex set (64 GiB). Consensus clients (supernodes) run on separate hosts and are not part of these numbers.
• Sync verification per client from container logs at measurement time (import lines at the live tip for Geth, Besu, Erigon, Ethrex; Nethermind additionally via its own head metric at block 25,294,914; Reth's April window as above). Metrics alone can read "synced" while a client back-fills, which is what Reth's June resync showed and why we check logs; see the pruning post for the long version.