Full Node vs Archive Node on Base: Key Differences and Setup Guide

The primary difference between running a full node and an archive node on Base is that full nodes store only the most recent blockchain state with older data pruned, while archive nodes persist the complete state trie for every block, enabling historical queries but requiring significantly higher storage and hardware resources.

Understanding whether to deploy a full node or an archive node is essential when setting up infrastructure for the Base network using the base/node repository. Your choice determines storage costs, synchronization time, and which JSON-RPC methods your node can successfully execute.

State Storage and Historical Data Access

Base nodes differ fundamentally in how they handle state data retention.

Full nodes maintain only the most recent state. The client prunes older blocks after a configurable distance, meaning the node cannot answer historical state queries for arbitrary past blocks. This configuration is sufficient for general transaction-relaying and block-proposal participation.

Archive nodes persist the full state trie for every block since genesis. This enables deterministic access to historic state data, allowing queries for any past balance, contract code, or storage value at specific block heights.

Querying Historical State

To execute a historic balance query, you must run an archive node. A full node cannot resolve this request:

curl -X POST http://localhost:8545 \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0xYourAddress","0x10d4f"],"id":1}'

Hardware Requirements and Storage Costs

The base/node repository provides explicit hardware specifications based on node type.

Full nodes require approximately 2× the current chain size plus snapshot and buffer space—roughly a few hundred GB for Base mainnet. While the repository recommends AWS i7i.12xlarge instances for both types, typical full node deployments often run with less disk allocation.

Archive nodes demand approximately 2× the current chain size plus full archival data, totaling multiple terabytes. According to README.md lines 61-68, the recommended hardware for a Reth archive node is explicitly an AWS i7i.12xlarge instance with RAID-0 NVMe drives and an ext4 filesystem.

Configuration and Deployment Differences

Node type selection is permanent and must be configured before the initial synchronization.

As documented in .env.mainnet lines 100-103, the node type cannot be changed after the first sync. Turning an Archive node into a Pruned/Full node, or vice versa, is not supported once the node has begun syncing.

To deploy a full (pruned) node using Geth:

NETWORK_ENV=.env.mainnet CLIENT=geth docker compose up --build

To deploy an archive node using Reth, ensure the PRUNING section remains commented out in your environment configuration:

# Ensure the PRUNING section in .env.mainnet is NOT uncommented

NETWORK_ENV=.env.mainnet CLIENT=reth docker compose up --build

Both configurations require setting OP_NODE_L1_ETH_RPC, OP_NODE_L1_BEACON, and OP_NODE_L1_BEACON_ARCHIVER as noted in the quick-start section of README.md lines 15-16.

Sync Performance and Operational Trade-offs

Full nodes offer faster initial synchronization because older state is discarded during the sync process. This makes them ideal for validators, transaction relayers, and most dApp interactions that only require the latest state.

Archive nodes require significantly longer initial sync times because they must download and retain every state transition. This trade-off is necessary for block explorers, analytics services, and indexing pipelines that require complete historical data.

When to Choose Each Node Type

Select a full node if you only need to interact with the live chain, send transactions, read current balances, or participate in block proposal while minimizing storage costs and synchronization time.

Select an archive node if you run block explorers, analytics pipelines, or any service requiring deterministic access to historic balances, contract code, or state at arbitrary block numbers.

Summary

• Full nodes prune historical state and require approximately a few hundred GB, suitable for current-state operations and general network participation.
• Archive nodes store complete state history for every block, requiring multiple TB and specific hardware (AWS i7i.12xlarge with RAID-0 NVMe) as specified in README.md lines 61-68.
• Node type is immutable after initial sync according to .env.mainnet lines 100-103.
• Archive nodes enable historical JSON-RPC queries like eth_getBalance at past block heights.
• Both node types require an L1 full node RPC endpoint configuration as documented in README.md lines 15-16.

Frequently Asked Questions

Can I convert a Base full node into an archive node?

No. According to the .env.mainnet configuration file lines 100-103, the node type chosen during the first run cannot be changed after the initial synchronization. Converting between Archive and Pruned/Full modes is not supported, requiring a complete resync from scratch if you need to switch types.

How much storage does a Base archive node require?

A Base archive node requires approximately 2× the current chain size plus full archival data, totaling multiple terabytes. This is significantly larger than full nodes, which require roughly a few hundred gigabytes. The base/node repository recommends AWS i7i.12xlarge instances with RAID-0 NVMe drives to handle these storage requirements.

Do I need different L1 infrastructure for full vs archive nodes?

No. Both full and archive nodes on Base require identical L1 infrastructure configurations. You must provide OP_NODE_L1_ETH_RPC, OP_NODE_L1_BEACON, and OP_NODE_L1_BEACON_ARCHIVER endpoints regardless of which node type you choose, as noted in the repository's quick-start documentation.

Which client is recommended for running a Base archive node?

The base/node repository explicitly recommends Reth for archive node operations. While Geth runs effectively in full/pruned mode, the documented hardware specifications and configuration examples in README.md lines 61-68 specifically target Reth for archival deployments requiring complete state history retention.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}