Skip to main content
Version: v3.5

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.
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.

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.

Pruning ModeCurrent Disk UsageDisk Size (Recommended)RAM (Required)RAM (Recommended)
Archive2.03 TB4 TB32 GB64 GB
Full (Default)419.04 GB2 TB16 GB32 GB
Minimal378.97 GB1 TB16 GB64 GB

Current Disk Usage measured as of 2026-07-19; 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~8 h~4–6 h~2 h
Gnosis~2 h~1–2 h~30 m
info

These figures are indicative and are not measured by CI — read them as an order of magnitude, not a target. Most of the elapsed time is snapshot download rather than block execution, so your available bandwidth influences the result more than CPU does: expect proportionally faster syncs on a well-connected host and slower ones on a constrained link.

Last updated on