Full Node vs Archive Node: What's the Difference (and Which Do You Need)?

"Do I need an archive node?" is one of the most common — and most expensive to get wrong — questions in blockchain infrastructure. Pick wrong one way and your indexer throws missing trie node halfway through a backfill. Pick wrong the other way and you're paying for (or self-hosting) fifteen terabytes of state you never query.

The confusing part is that "full" and "archive" sound like a completeness spectrum, as if a full node is missing some history. It isn't. Both node types have every block, every transaction, every receipt, and every event log, all the way back to genesis. You can look up a five-year-old transaction on a plain full node without issue.

The difference is exactly one thing: historical state.

State vs history

Two different things live on a chain, and conflating them is the root of the confusion:

• History — blocks, transactions, receipts, logs. Immutable records of what happened. Both full and archive nodes keep all of it.
• State — the actual values at a point in time: account balances, contract storage slots, nonces, deployed code. This is a giant key-value tree (the "state trie") that changes with every block.

A full node keeps the current state plus a short rolling window of recent state (Geth keeps roughly the last 128 blocks). Older state is pruned — thrown away — because it can be recomputed from genesis if you ever truly need it, and keeping it is enormously expensive.

An archive node never prunes. It keeps the full state trie at every block in history, so it can tell you an account's balance or a contract's storage at any block that ever existed.

The one test that settles it

Ask yourself: am I reading state at a past block?

Every Ethereum state-reading method takes a block parameter — eth_call, eth_getBalance, eth_getStorageAt, eth_getCode. Pass latest (or a block from the last few minutes) and a full node answers fine. Pass a block from last week and a full node has nothing to give you:

import { createPublicClient, http } from "viem";
import { mainnet } from "viem/chains";

const client = createPublicClient({
  chain: mainnet,
  transport: http("https://rpc.swiftnodes.io/rpc/eth?key=YOUR_API_KEY"),
});

// Fine on a full node — current balance
await client.getBalance({ address: "0xabc..." });

// Needs an ARCHIVE node — balance at a specific historical block
await client.getBalance({ address: "0xabc...", blockNumber: 18_000_000n });

On a pruned full node, that second call comes back as missing trie node or header not found. On an archive node, it just works. Same story for eth_call reading a contract's state at a past block, and for transaction tracing — debug_traceTransaction and the trace_* methods replay a transaction against the state as it was, which requires that historical state to exist. (We dug into when tracing is worth its cost in the real cost of debug_traceTransaction.)

Which one does your app need?

A useful rule of thumb: if your code never writes a past block number into a state call, you don't need archive. The single most common reason teams think they need archive but don't is event indexing — eth_getLogs reads logs, which are history, so a full node serves it (subject to range caps, which we covered in how eth_getLogs range caps bite you).

Why archive is the expensive one

The pruning a full node does isn't laziness — it's the difference between a node you can run on a normal SSD and one you can't.

That 10×+ storage gap is why archive access costs more everywhere — whether you're buying the drives yourself or paying a provider. The good news is that modern clients (Erigon, Reth) have collapsed archive storage from Geth's ~15 TB to roughly 3 TB with a flat-state layout, which is what makes affordable archive RPC possible at all. If you're weighing self-hosting, we ran the full numbers in the cheapest way to run an Ethereum archive node — short version: for most teams a provider is dramatically cheaper than the hardware plus the weeks of sync and babysitting.

How this maps to RPC providers

Because archive is the costly tier, most providers treat it as a paid upgrade — gated behind a higher plan, or billed at a premium per call. So before you commit, check two things: whether archive depth is included or extra, and whether it's available on the chains you actually use (archive support is uneven across L2s and alt-L1s).

SwiftNodes serves archive-depth queries across our supported chains on the same flat-rate key as everything else — no separate archive tier, no per-call surcharge when you pass a historical block number. Point your eth_call at our Ethereum RPC with any block tag and it resolves, current or historical.

The short version

A full node answers "what is true now"; an archive node also answers "what was true then." Both have all the blocks and logs. If your app reads account or contract state at a past block — accounting, analytics, historical DeFi, transaction tracing — you need archive. If it lives in the present — wallets, dApps, log indexing — a full node is all you'll ever touch, and paying for archive is money lit on fire.

Not sure which your workload lands on? Grab a free key at swiftnodes.io, point it at any chain, and try your query with a historical block number — if it resolves, you're covered either way.