Skip to main content

Hardware Requirements

Overview​

A locally mounted SSD (Solid-State Drive) or NVMe (Non-Volatile Memory Express) disk is essential for optimal performance. Avoid Hard Disk Drives (HDD), as they can cause Erigon to lag behind the blockchain tip, albeit not fall behind.

ComponentRecommendationNotes
Disk TypeUse high-end NVMe SSDs.Avoid HDDs. SSD performance may degrade when nearing full capacity.
Disk ConfigurationA single NVMe device is enough for any pruning mode.An archive node fits on one 4 TB drive, so RAID 0 striping is not needed. For failure protection, use a mirrored array, not RAID 0. See Filesystem.
Filesystemext4 or XFSSee Filesystem below.
RAMAdequate memory is crucialReduces bottlenecks during sync and improves performance under load.
CPU4–8 cores for Full nodes, 8–16 cores for Archive nodesMore cores are generally better for intense sync and query operations. On amd64, the CPU must support the x86-64-v2 baseline (SSE4.2, POPCNT): Intel Nehalem (2008), AMD Bulldozer (2011) or newer.
LinuxKernel version > v4A modern Linux distribution is required.

Filesystem​

Use ext4 or XFS on a single NVMe device. The disk figures below are measured on ext4, and that is the configuration Erigon's own measurements come from. XFS is a reasonable choice on the same reasoning, but we have not measured it.

Mount with noatime so reads do not generate metadata writes:

UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx  /data  ext4  defaults,noatime  0 2

Use the filesystem UUID (blkid prints it) rather than a /dev/nvme… name, which can move between boots. The final 2 is the fsck pass for a non-root filesystem.

Why the filesystem matters​

Erigon's bottleneck is disk latency, not throughput or IOPS — see Improving Performance. Erigon does pre-warm what it can, but two properties of the workload mean its reads cannot be fully predicted, so part of every block's reads lands cold:

  • EVM execution reads arbitrary state. Nothing tells you in advance which accounts or storage slots a block will touch. Once the working set no longer fits in RAM, some of those reads land on cold data no cache had reason to hold.
  • Merkle trie updates pull in neighbours. Updating one key requires reading the nodes next to it in the trie. Those may be accounts the EVM never touches — they are involved only because of where they sit in the trie.

Every layer the filesystem adds is added on top of each of those reads. That is what favours a thin filesystem here: ext4 and XFS store a file and leave caching to the OS page cache, which is what Erigon's memory-mapped database is built to use.

Filesystems to avoid​

Prefer a plain journaling filesystem over a copy-on-write or database-like one:

  • ZFS behaves more like a database than a filesystem. It keeps its own write-ahead log and its own cache (ARC), and that cache competes with the OS page cache for the same RAM. Optional features such as encryption and dedup add work to the read path this workload is bound by, and tuning ZFS for it is not a solved problem.
  • Btrfs is a copy-on-write B-tree of pages, and Erigon's MDBX database is itself a B-tree of pages, so you end up running a database inside a database. Its autodefrag feature is the sharpest edge: it can multiply write I/O by as much as 100x. See Background File System Features Can Hurt Performance.

Filesystems other than ext4 and XFS are not part of what we measure, so treat their performance as unverified rather than assumed.

note

Erigon checks this for you at startup. It detects the filesystem type behind each of its directories — which may sit on different mounts — and logs one warning per unrecognised type:

WARN [diskutils] Filesystem is neither ext4 nor XFS, performance is unverified  fstype=zfs paths=/data/erigon see=https://docs.erigon.tech/get-started/hardware-requirements

It is a warning, not a refusal: the node starts and runs either way. A type Erigon cannot detect is logged at debug level instead, so no warning does not by itself confirm ext4 or XFS.

A few more points that follow from Erigon's storage model — see Database for the layout:

  • One device is enough. An archive node fits on a single 4 TB drive, so RAID 0 gains you no capacity you need while doubling the chance of losing the datadir. Stripe only if no single drive you have is large enough.
  • For failure protection, use redundancy — not RAID 0. A mirrored array and ECC memory guard against a failing disk or bad RAM, which is what Best Practices recommends. RAID 0 does the opposite.
  • Most of the datadir is re-downloadable. Snapshot files are content-addressed and refetched from peers, so chaindata/ is the part worth backing up.
  • Erigon memory-maps its database. Leave RAM free for the page cache rather than handing it to a filesystem or volume manager to cache on its own.
  • Network and cloud block storage are slow for block execution. See known issues.

If you must split the datadir across a fast and a slow device, see Optimizing Storage.

Disk Size and RAM Requirements​

The amount of disk space recommended and RAM you need depends on the pruning mode you want to run. Current Disk Usage values listed below are obtained using the standard Erigon + Caplin configuration, varying only the --prune.mode flag unless a tab notes otherwise. Each figure is the size of the whole datadir with the node stopped, excluding the transient temp/ directory.

note

These nodes were measured before the receipts cache was on by default. From 3.7 it is on, which adds about 441 GB on a mainnet archive node and a few GB on full and minimal nodes, whose receipts follow their history window. See Database. The recommended disk sizes below already leave room for it.

Pruning ModeCurrent Disk UsageDisk Size (Recommended)RAM (Required)RAM (Recommended)
Archive2.25 TB4 TB32 GB64 GB
Full (Default)534.94 GB2 TB16 GB32 GB
Minimal510.82 GB1 TB16 GB64 GB

Current Disk Usage measured as of 2026-09-17, the oldest of the measurements in this table; usage grows over time as the chain grows.

tip

See also how you can optimize storage.

Bandwidth Requirements​

Your internet bandwidth is also an important factor, particularly for sync speed and validator performance.

Node TypeBandwidth (Required)Bandwidth (Recommended)
Staking/Mining10 Mbps50 Mbps
Non-Staking5 Mbps25 Mbps

Sync Times​

Approximate times to sync from scratch to the tip of the chain.

ChainArchiveFull (Default)Minimal
Ethereum~14 h 20 m~5 h 40 m~5 h 20 m
Gnosis~5 h 15 m~2 h 50 m~2 h 50 m
info

Measured on Erigon 3.6.1 in September 2026, syncing each node from an empty datadir on one machine (16-core Intel Core Ultra 9 185H, 93 GB RAM, NVMe SSD on ext4), one node at a time. Time is measured from process start to the first report of a head at the chain tip.

The download rate was capped at 400 Mbps, and that cap — not the hardware — is what set these times. Most of the elapsed time is snapshot download rather than block execution, so your available bandwidth influences the result far more than CPU does. Note that 400 Mbps is eight times the 50 Mbps recommended above for a staking node: on a link at that recommended speed, expect these times to be several times longer, with block execution rather than download eventually setting the floor. Treat them as an order of magnitude, not a target — they are a single sample per configuration, with no variance estimate, and sync time also depends on peer quality and chain activity on the day.

Note that full and minimal land within a few percent of each other on both chains. The gap between them is small; the gap to archive is about 1.9× on Gnosis and 2.5× on Ethereum.

Last updated on