The difference between an archive node and a full node comes down to one question: do you need to read blockchain state as it existed at some point in the past? A full node answers questions about recent and current state; an archive node keeps every historical state back to the first block and can answer "what was this balance at block 10,000,000?" Most applications never ask that question, which means most teams paying for archive access are paying for capacity they do not use. This guide explains exactly what each node type stores, which queries require which type, what the storage really costs, and how to decide without overbuying.
What each node type actually stores
Ethereum's own documentation draws the line cleanly. A full node performs "a block-by-block validation of the blockchain, including downloading and verifying the block body and state data for each block" — but it periodically prunes old state, so it "does not store all state data back to genesis." An archive node is a full node that "never delete[s] any of the downloaded data," building an archive of every historical state along the way.
The key insight is that pruning does not throw away history itself. A full node still has every block and every transaction ever included. What it discards is the computed state — the account balances, contract storage values, and code as they stood after each old block. Current state is always there. Recent state (roughly the last 128 blocks in most clients) is there too. It is only the deep historical snapshots that a full node lets go.
There is a third tier worth naming: light nodes download only block headers and fetch everything else on demand. They are for constrained environments, not for serving applications, so the real decision for anyone building something is between full and archive — or between running either one and renting access to someone else's.
A useful mental model: the blockchain is a ledger of events (transactions), and state is the result of replaying those events. Full nodes keep the ledger and the latest result. Archive nodes keep the ledger and every intermediate result. Because results can always be recomputed from events, an archive node stores nothing a full node could not eventually reconstruct — it just trades an enormous amount of disk for the ability to answer historical questions instantly instead of re-executing years of transactions.
If terms like state, RPC methods, or client software are new, our primer on blockchain RPC and node infrastructure covers the foundations this article builds on.
Full node vs archive node: how far back do your reads reach?
Sort your queries into two buckets and the choice makes itself.
Full-node territory — everything about the present and the recorded past:
- Current balances, token holdings, and contract state
- Sending transactions and estimating gas
- Reading any historical block or transaction (these are permanent records, not pruned state)
- Event logs via
eth_getLogsacross historical ranges — logs are stored with receipts, and clients index them without needing archive state - Anything a typical wallet, dapp frontend, minting site, or payment integration does
Archive territory — recomputing the past as it stood:
eth_callagainst an old block: "what would this contract view function have returned at block N?"eth_getBalanceoreth_getStorageAtfor blocks older than the recent-state window- Historical snapshots for accounting: token balances of thousands of holders as of a specific date
- Tracing old transactions (
debug_traceTransactionand similar) to reconstruct exactly what a transaction did internally - Research over state evolution: DAO voting power over time, collateral ratios through a crash, protocol TVL reconstructed from state rather than events
Notice how specific the archive bucket is. It belongs to indexers, tax and accounting tools, forensic investigators, protocol researchers, and block explorers. A production dapp serving users touches the present almost exclusively. Plenty of teams discover this only after provisioning archive infrastructure: their actual query log never reaches past last week, and the entire premium was spent on insurance against queries nobody runs.
One honest complication: some workloads look historical but are not, and some look current but are not. Rebuilding a DEX's trade history is event work — logs, not archive state. Verifying what an oracle reported at a specific block inside a dispute is state work — archive. When in doubt, write down the exact RPC calls your feature makes, with the block parameter each one passes. If the block parameter is always latest or within the last few minutes, you are a full-node workload.
More in Node & RPC Infrastructure
What archive data costs to run yourself
Storage is the whole story, and the client you pick changes it dramatically.
Reth's published system requirements (as of June 2025, around block 22,700,000) call for at least 1.2TB of NVMe disk for a full node and at least 2.8TB for an archive node, with 8GB and 16GB of memory respectively. Ethereum.org notes that Erigon "can perform a full archive node sync using around 2TB of disk space, in under 3 days." These modern clients rewrote historical-state storage specifically to make archives practical; older approaches to archive storage consumed well over five times as much disk, which is where the folk wisdom that "archive nodes need a data center" comes from. It is outdated for current clients but persists in tutorials.
The archive premium with a modern client is therefore roughly 1.5–2TB of extra NVMe over a full node, plus a longer initial sync and somewhat heavier database maintenance. At typical dedicated-server storage pricing this is tens of dollars per month of difference, not hundreds — the real cost is operational: bigger backups, longer resyncs when something corrupts, and a database whose performance characteristics you now have to care about. Our guide to running your own Ethereum node covers the baseline operations either node type demands; if hosted usage limits are what pushed you here, the practical fixes in how to fix RPC rate limit errors may be the cheaper answer.
Remember also that an execution-layer node does not run alone: post-merge Ethereum requires a consensus client alongside it, which adds its own disk (typically a few hundred gigabytes) and memory footprint on the same machine.
Growth is the other budget line people forget. The chain adds state and history continuously, so whatever disk figure you provision against is a snapshot, not a ceiling. A full node's pruned footprint grows slowly because pruning keeps reclaiming space; an archive grows by definition, since it never deletes. Planning an archive machine means planning its second disk, or at least choosing a chassis that accepts one. Budget for the size the node will be in two years, not the size it is on sync day.
Sync time deserves a line of its own too. A full node using snap sync can be serving traffic within hours to a day on good hardware. An archive sync re-executes history and takes days even on the fastest clients — Erigon's under-3-days figure is the optimistic end, on NVMe, with good peers. That difference matters operationally: if your archive database corrupts, your recovery time is measured in days unless you keep a second synced machine or a recent snapshot. Teams whose product depends on an archive endpoint almost always end up running two.
Node types compared
The table converts each option into what it can answer and what the storage premium buys, using Reth's published requirements as the reference client. The derived column — disk per year of queryable history — is the honest way to see what the archive premium purchases: Ethereum has roughly a decade of history, so 2.8TB of archive spread over it is about 280GB per queryable year, while a full node concentrates its 1.2TB on just the current tip.
| Setup | Disk (Reth, mainnet) | Historical state queries | Disk per year of queryable state history | Best fit |
|---|---|---|---|---|
| Light node | A few GB | None | n/a | Wallets on constrained devices |
| Full node | ≥1.2TB | Last ~128 blocks only | ~1.2TB for ~25 minutes of history | Dapps, wallets, bots, payments |
| Archive node (modern client) | ≥2.8TB | Any block since genesis | ~280GB per year | Indexers, explorers, research, accounting |
| Hosted archive access | 0 (provider's disk) | Any block, metered per call | n/a | Occasional historical queries |
That last row is the one most teams should sit with. Hosted providers expose archive methods on metered plans, which means occasional historical queries — a monthly accounting snapshot, a one-off investigation — cost pennies, while the always-on archive machine costs the same whether you query it once or a million times. The crossover logic mirrors any rent-versus-buy decision: rent while historical queries are rare, buy when they are your product.
Choose a full node if your block parameters are latest or near it — this is the correct default and covers dapps, bots, and wallets. Choose hosted archive access if you need historical state occasionally or unpredictably, because per-call pricing beats idle hardware. Choose your own archive node if historical state queries are core to your product and run constantly — indexers, explorers, analytics — or if you trace transactions at volumes where hosted per-call costs compound. Skip the archive if you cannot name the specific RPC method and old block parameter you need it for; "we might need history someday" is not a workload, and you can add an archive later without losing anything, since all history can be rebuilt from the chain itself.
Which setup fits your situation
Situation 1: A dapp team told they "should probably get archive access"
Your app reads current prices, balances, and positions, and someone suggested archive infrastructure as a safety measure. Audit your actual calls first: list every RPC method your code makes and the block parameter it passes. If everything says latest, a full node or a standard hosted plan covers you completely, and the archive premium buys nothing. The one wrinkle to check is event-log backfills — those are heavy but they are log queries a full node serves; the fix for their cost is batching and checkpointing, not archive state.
Situation 2: A tax, accounting, or compliance tool that reconstructs balances at dates
You need wallet balances and positions as they stood at year-end or at each transaction date — textbook archive queries against old blocks. Volume decides the build-or-rent question. A reporting tool that snapshots thousands of accounts quarterly can rent hosted archive calls for a fraction of a machine's cost. A platform doing continuous historical reconciliation across many customers crosses into own-archive territory fast, and with Erigon or Reth the hardware is a single sub-3TB NVMe server, not the rack the old numbers implied.
Situation 3: An indexer or explorer replaying chain history into a database
You are building the product category archive nodes exist for: replaying every transaction, tracing internal calls, and materializing state history into your own queryable form. Run your own archive node with a modern client — tracing workloads hammer the endpoint far past what metered hosted plans price sanely, and sync-from-scratch speed matters every time you change your schema and reindex. Erigon's roughly 2TB / under-3-days archive sync, per ethereum.org, is the benchmark to compare clients against; put the database on the fastest TLC NVMe the budget allows, since trace throughput lives and dies on disk latency.
Common mistakes when choosing
Three errors account for most wasted node budgets.
The first error: Buying archive because a tutorial did. Indexing tutorials are usually written by and for indexer builders, and their infrastructure sections assume archive access. If you followed one to build a frontend, you inherited requirements from a different product category. Re-derive your needs from your own RPC calls, not from the tutorial's shopping list.
The second error: Confusing "historical data" with "historical state." The word "historical" appears in both buckets, and it misleads. Historical transactions, blocks, and logs live on every full node forever. Historical state — what a balance or a storage slot held at an old block — is the only thing that needs an archive. Say "state" out loud when you scope a feature; if the sentence still makes sense, you need the archive, and if it becomes nonsense, you do not.
The third error: Sizing from stale numbers. Disk figures for nodes go stale in both directions: the chain grows (numbers rise) and clients improve storage layouts (numbers fall). A 2022 blog post's archive estimate can be off by a factor of five from today's Reth or Erigon reality. Always pull the requirement from the client's own current documentation on the day you provision, and note the block height it was measured at.
FAQ
Can I query any historical transaction on a full node? Yes. Transactions and blocks are permanent records that full nodes keep entirely. What a full node cannot do is recompute state — balances, storage, contract views — at old blocks. "Show me transaction X from 2021" works; "show me the balance of this address the moment before transaction X" needs an archive.
How far back can a full node serve state queries? Most clients hold roughly the last 128 blocks of state — about 25 minutes on mainnet. Beyond that window, state calls against old blocks return errors indicating the state is unavailable. The exact retention varies by client and configuration, but it is minutes-to-hours, never months.
Can I upgrade a full node to an archive node later? Not in place — archive data comes from executing every block with full state retention, so converting means resyncing from genesis in archive mode on a bigger disk. The good news: you lose nothing by waiting. History is always reconstructable, so deferring the archive until a real workload appears is free insurance in reverse.
Do event logs require an archive node? No, and this is the most common confusion in the whole topic. Logs are emitted by transactions and stored alongside receipts; full nodes serve eth_getLogs across the chain's entire history. Indexing a token's complete transfer history is a full-node job. Only recomputing state at old blocks needs the archive.
Does running an archive node earn anything extra? No. Validation and staking rewards depend on the consensus layer, and an archive node validates exactly as a full node does. The archive is purely a data-access capability: it changes what questions you can ask your own node, not what the network pays you. Run one because your product needs historical state, never as an income strategy.
Why do different sources quote wildly different archive node sizes? Client architecture. Older storage designs kept every historical state trie explicitly and ballooned past 12TB on mainnet. Erigon and Reth store history in flat, deduplicated formats — roughly 2TB and 2.8TB respectively per their current published figures — so an "archive node" costs radically different amounts depending on which client the number describes and when it was measured.
Sources
[Ethereum.org
[Reth documentation
[Alchemy pricing
