A full node and an archival node both validate the chain and both store the current state. The difference is history. A full node keeps recent state and prunes older state to save disk. An archival node keeps every historical state, from genesis to the latest block, so it can answer questions about any past block instantly. That one difference decides disk size, sync time, cost, and which applications each node can serve. Choose wrong and you either pay for history you never query, or you discover mid-project that the history you need was pruned months ago.
Start with the question your app actually asks. If it asks "what is true now" - a current balance, a current token supply, whether a transaction is confirmed - a full node is enough. If it asks "what was true then" - a balance at a specific old block, a contract state from last year, a trace of a historical transaction - you need archival data. Most wallets, payment flows, and real-time dapps live in the first group. Explorers, indexers, analytics platforms, and auditors live in the second.
Full node, in plain English
A full node downloads and validates blocks, keeps the full block history, and keeps the current state plus roughly the last 128 blocks of historical state on Ethereum. Older state is pruned: deleted to conserve storage, with the understanding that it can be recalculated if truly needed, at the cost of extra computation. That pruning is why a full node is practical. It serves every current-state query a normal app needs, without carrying the full weight of every state the chain has ever had.
The practical limit shows up when you query old state on a full node. Ask for a balance or a contract call at a block from months ago and the node cannot answer from stored state: it will fail, often with a missing trie node error, because that state was pruned. That is not a bug. It is the design trade. If your app never makes those queries, the trade costs you nothing. If it does, the trade costs you a migration at the worst possible time.
Archival node, in plain English
An archival node is a full node that does not prune. It stores every state snapshot since genesis: every account balance, every contract storage value, at every block height. Ask it what an address held at block 5,000,000 and it answers from disk, fast, without reconstruction. That is why explorers can show you a transaction from years ago, why analytics platforms can backfill a full history, and why auditors can replay state at any point.
The price is disk, sync time, and operations attention. Archival storage is several times larger than full-node storage, and the gap varies enormously by client. As a rough, client-dependent guide quoted in node documentation roundups: a Geth archive is often quoted above 12TB, while the more storage-efficient Erigon client brings an archive down to roughly 2TB. Those figures change with client versions and chain growth, so check the client docs on the day you plan, and budget for growth, not just for today's size. Sync time follows the same pattern: hours to days for a full node, days to weeks for an archive, depending on hardware and network.
Cost and disk, side by side
Full node: moderate disk (a few terabytes for Ethereum mainnet, varying by client and pruning settings), faster sync, lower hosting cost, and enough for wallets, dapps, payments, and real-time reads. Archival node: much larger disk, slower sync, higher hosting and backup cost, and required for explorers, indexers, historical analytics, audits, and trace APIs. Light nodes sit below both: block headers only, small and fast, but dependent on full nodes for data, and not a substitute for either when your app needs verified state itself.
Disk growth is the hidden cost in both cases. Chains grow every week, and an archival node grows faster in absolute terms because it keeps everything. Plan disk headroom for months, monitor growth weekly, and have a migration plan for the day a disk fills. A node that runs out of disk does not degrade gracefully. It stops, and a stopped archival node takes a long time to catch up again. That is an operations failure, not a hardware surprise, if growth was visible for weeks.
Decision table by use case
Wallet or payment app: full node. You need current state, fast, reliably. Dapp with real-time reads: full node, with a private RPC layer and a fallback. Explorer, indexer, or analytics platform: archival node, or archival access from a provider if you do not want to run one. Auditor or researcher replaying history: archival node. Smart contract developer debugging a past deployment: archival access, at least temporarily, because a full node will not answer old-state calls. When in doubt, ask which block heights your queries actually touch. If the answer is "latest", you do not need archival. If the answer includes specific old blocks, you do.
Can you upgrade a full node to archival later? In practice, no, not by flipping a setting. An archival node must record state from the start, or resync from genesis with archival mode enabled. That resync is the cost of deciding late. If there is a realistic chance you will need historical queries within the life of the project, start archival, or secure archival access from a provider from day one, rather than assuming a later conversion will be painless.
Do wallets need archival nodes? No, not for normal use. A wallet reads current balances and submits transactions, both full-node jobs. Do indexers need archival nodes? Usually yes, because backfilling history is the core job of an indexer. The confusion comes from providers that label any large node "archive". Check what the node actually stores and which methods it serves for old blocks, rather than trusting the label.
If you are choosing between the two for a real product, blockchain node setup and DevOps node operations cover sizing, sync strategy, and cost control, starting with a free infra audit of your query pattern. Bring the list of queries your app actually makes, including the oldest block height it touches: that list alone usually settles the full-versus-archival decision in one conversation.
Disclaimer: This post is educational only, not financial advice. Figures are listing or project data as of 2026-10-29 and may change - always confirm version numbers, requirements, and dates in the official docs before acting on them.