Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/ethereum/go-ethereum/llms.txt

Use this file to discover all available pages before exploring further.

Geth supports two sync modes controlled by the --syncmode flag, plus an archive option controlled by --gcmode. Each makes a different tradeoff between initial sync speed, ongoing disk usage, and the historical data it can serve.

​
Snap sync (default)

Snap sync is the default and fastest way to get a node up to date. Instead of re-executing every transaction since genesis, Geth downloads a recent snapshot of the Ethereum state and then fills in block headers and bodies around it. 
geth --syncmode snap
Because snap sync skips transaction re-execution for the bulk of the chain, it requires far less CPU than full sync. Once the state snapshot is downloaded and verified, the node switches to following the chain tip normally.
snap is the default sync mode. Running geth without any --syncmode flag is equivalent to geth --syncmode snap.

​
How it works

The snap protocol (defined in eth/protocols/snap) transfers a compact representation of the current state trie directly between peers. Geth also retrieves at least the last 64 blocks in full so that it can validate the recent chain and handle small re-organisations.

​
Hardware requirements

ResourceMinimumRecommended
CPU cores48+
RAM8 GB16 GB
Disk (SSD strongly recommended)1 TB free1 TB+ SSD
Bandwidth8 Mbit/s25+ Mbit/s
A high-performance NVMe SSD makes a significant difference. Snap sync writes large amounts of data during the initial state download, so disk I/O throughput matters more than raw disk size.

​
Full sync

Full sync downloads every block from genesis and re-executes all transactions to rebuild the chain state from scratch. It is the most thorough validation method but is significantly slower than snap sync. 
geth --syncmode full
With full sync, Geth still prunes old trie state by default (--gcmode=full). Only the current state is kept on disk; historical states are discarded after they are no longer needed for re-organisations.

​
When to use full sync

Maximum trust

You independently validate every transaction and state transition since the genesis block.

Reproducibility

Useful when you need to confirm the chain from first principles without relying on peer-supplied state snapshots.

​
Hardware requirements

Full sync has the same disk footprint as snap sync once complete (both prune old state by default), but takes considerably longer — plan for multiple days on mainnet.
ResourceMinimumRecommended
CPU cores48+
RAM8 GB16 GB
Disk (SSD required)1 TB free1 TB+ NVMe SSD
Bandwidth8 Mbit/s25+ Mbit/s

​
Archive mode

Archive mode retains all historical state — every account balance, contract storage slot, and code at every block height since genesis. It is enabled via --gcmode=archive and can be combined with either sync mode. 
# Archive node using snap sync (fastest initial sync)
geth --syncmode snap --gcmode archive

# Archive node using full sync (maximum verification)
geth --syncmode full --gcmode archive
Archive nodes require substantially more disk space than pruned nodes. Mainnet archive storage grows continuously and currently exceeds several terabytes. Plan accordingly and use an expandable storage setup.

​
When you need archive mode

Archive mode is required when you need to query historical state — for example, calling eth_getBalance for an address at a block number far in the past, or running debug_traceTransaction on old transactions. Block explorers, analytics platforms, and some dApp backends depend on archive data.

​
Hardware requirements

ResourceMinimumRecommended
CPU cores48+
RAM16 GB32 GB
Disk (NVMe SSD required)4 TB free8 TB+ NVMe SSD
Bandwidth8 Mbit/s25+ Mbit/s

​
Light sync (removed)

Light sync (--syncmode light) has been removed from Geth. The light client protocol depended on servers that were willing to serve light clients, and that infrastructure is no longer actively supported. If you need a lightweight Ethereum client, consider a dedicated light-client project or use the Ethereum JSON-RPC API provided by a trusted full node.

​
Tradeoffs summary

  • Speed: Fastest initial sync (hours on a good connection)
  • Storage: ~1 TB (mainnet, pruned)
  • Historical data: Current state + recent blocks only
  • Best for: Most users, validators, dApp backends that do not need historical state

Build docs developers (and LLMs) love

Get started for freeTalk to us