Nodes store and verify different subsets of network data depending on the protocol, client, and configuration. On Ethereum, three setups come up most often: a full node keeps current state and validates new blocks, an archive node adds retained historical state, and a light node (or light client) stores almost no chain data and verifies proofs instead. Those differences drive disk space, sync time, cost, and which queries a node can answer.
One caveat before the details: these labels are clearest on Ethereum and Ethereum-style networks. Bitcoin and other chains use different storage models and terminology — a “pruned” Bitcoin node, for example, is still a fully validating node, not a lesser tier. This guide walks the three types from simplest to most demanding, then covers how to reach any of them without running the hardware yourself.
What does it mean?
Full node (Ethereum): a node that maintains the current state and independently validates every new block against consensus rules. Depending on the client and pruning settings, it may also retain historical block bodies and receipts — state pruning and history pruning are separate options.
A full node enforces the protocol’s rules for itself, which is the practical meaning of “don’t trust, verify.” Its client decides how much history it keeps: state pruning discards old state data, while history pruning trims old block bodies and receipts, and the two are configured separately. So “full node” describes a family of configurations, not one fixed footprint.
It’s also worth correcting a common myth. A modern full node does not re-execute every block from the genesis block on first sync — Geth’s default snap sync downloads a recent state snapshot and verifies forward from a trusted checkpoint, as described in Geth’s sync-modes docs. Full validation of the canonical chain still happens; it just doesn’t mean sequentially executing all of history during initial sync.
Storage depends on the execution client, consensus client, sync mode, pruning, and retained indexes, so treat any single number with caution. As a planning baseline, Geth’s hardware guide recommends a 2 TB+ SSD, and real-world occupied space varies widely across clients and configurations — which is why a storage comparison should name the setup it measured.
Full nodes fit the largest group of operators — wallets, dApp backends, and individuals who want to validate independently. A full node lets you broadcast signed transactions through the node and read current state directly; it does not “write” to chain state, since only consensus produces new state. For most projects that don’t need deep history, this is the sensible default.
Archive node (Ethereum): a full node configured to retain historical state — account and contract values at past blocks — so it can serve historical-state queries without re-executing the chain. On Geth’s modern path-based scheme, the retained range is configurable.
An archive node answers a question like “what was this contract’s storage at block 12,000,000?” directly, instead of reconstructing it. That capability powers explorers, analytics, and tooling that reads deep history. On modern Geth, though, “archive” isn’t all-or-nothing: path-based archive mode supports configurable state-history retention, and only a configuration that keeps the entire range provides complete historical state from genesis.
The storage cost is real and worth stating precisely. Per Geth’s documentation, a path-based archive retaining full flat state history needs roughly 2 TB, while storing flat states together with historical trie data can require around 6.5 TB, and a path-based archive sync can take on the order of two weeks. More storage-efficient clients such as Erigon exist, but published footprints vary by version and flags, so confirm against a current official benchmark before provisioning.
One nuance: archive state is needed specifically for queries about historical account or contract state beyond a node’s retained window. Old block bodies, transactions, and receipts can still be available on a non-archive node, so not every historical call requires an archive. Tracing is similar — whether a trace call works depends on the client, method, retained history, and re-execution limits, and some recent transactions can be traced without a full archive.
The Core Difference
Here’s the full node vs archive node distinction in one line: a full node serves current state, an archive node also serves retained historical state. Both apply the same consensus rules, and both can independently validate the chain when correctly configured — the primary difference is retained historical state, not validation rules. A full node can still report today’s value of any address; it just may not hold that address’s value from 400,000 blocks ago.
Can a full node reconstruct that old value? Sometimes — but qualify it by client and retained data. Rebuilding historical state can require extensive re-execution, a resync, or data the node no longer holds, and it isn’t exposed as an automatic fallback for every query. That gap is the heart of the archive node vs full node difference: an archive setup pays for storage up front so historical reads are immediate.
How the Labels Map to Bitcoin and Other Networks
These categories travel poorly across chains, so it’s worth being explicit. Bitcoin has no separate “archive node” mode in the Ethereum sense; a Bitcoin full node validates the entire chain during initial sync, and a pruned Bitcoin node is still a fully validating node that simply deletes older raw block and undo data afterward. Pruning there is a disk-management setting, not a downgrade in validation.
Bitcoin’s chain data is time-sensitive, too. It stood at roughly 753 GB as of July 2026 per YCharts, growing about 6–7 GB a month, so recheck the current figure near publication. A pruned node can cut stored block data sharply by setting a prune target, but that target is only the block-file budget — the chainstate (the UTXO set), any optional indexes, and operating overhead sit on top, so the total footprint is larger than the prune number alone.
Light node / light client: a node that does not store or execute the full chain. On Ethereum it tracks authenticated consensus headers and requests execution data and proofs on demand, verifying them cryptographically. (“Light node” and “light client” are used interchangeably.)
A light client is the minimalist option, but it isn’t just a chain of proof-of-work headers like an early Bitcoin SPV client. On Ethereum it follows the beacon chain’s authenticated consensus updates and asks full or archive nodes for specific execution data and proofs when a user needs them, then checks those proofs against what it has verified. That’s what lets a mobile wallet confirm a payment without downloading hundreds of gigabytes.
The mechanism behind this is the sync committee. Ethereum selects a 512-validator sync committee every 256 epochs, approximately 27 hours, and those validators sign recent headers for light clients to verify. A light client still relies on a recent trusted checkpoint under Ethereum’s weak-subjectivity model and depends on providers or peers for data availability, even as it verifies the cryptographic proofs itself. As a performance example, a16z reports its Helios client syncing in about two seconds under its tested conditions — a Helios figure, not a guarantee for every device or provider.
Implementations differ in maturity rather than sharing one readiness label; Ethereum’s light-client docs list several projects at different stages of development. The tradeoff is scope, not blind trust: a light client verifies the consensus and state relevant to its requests, but it does not download and execute every transaction or maintain the full state. For end-user apps where footprint and speed matter most, that’s a reasonable trade — which is why light clients tend to power wallets rather than exchange backends.
Key Differences
The table below summarizes the storage, validation, and common uses of each node type. Figures are Ethereum-specific and depend on client, sync mode, and pruning, so read them as ranges to verify rather than fixed values.
| Feature | Full node | Archive node | Light node |
|---|---|---|---|
| Data retained | Current state; some history by config | Historical state (retention configurable) | Authenticated headers; proofs on demand |
| Historical-state queries | Limited; may need re-execution or resync | Direct, within retained range | Limited; depends on external providers |
| Validation | Independent, when configured correctly | Independent, when configured correctly | Verifies proofs and consensus updates |
| Storage (Ethereum) | ≥ 2 TB SSD recommended; varies by setup | ~2 TB flat, up to ~6.5 TB with trie (Geth) | Minimal; no full chain stored |
| Initial sync | Hours to days (sync-mode dependent) | Up to ~2 weeks (Geth path-based) | Seconds (Helios, reported) |
| Typical use | Wallets, dApp backends, validation | Explorers, analytics, deep history | Mobile and lightweight apps |
How to Choose the Right Type
Match the node to the question your app asks most often. If you mainly validate and broadcast against current state, a full node is the balanced pick. If your product sells history — a block explorer, an analytics tool, historical-state APIs — budget for an archive configuration and its storage. And if you’re shipping a mobile or lightweight client, a light client keeps the install tiny.
One caution: node type alone doesn’t describe a production architecture. Exchanges and other high-traffic services usually layer in redundancy, indexing, high availability, and sometimes archive access, rather than running a single node of any one type. Treat it as one decision inside a larger infrastructure design.
Run Your Own or Use a Provider
There’s also the question of whether to run the hardware yourself. Plenty of builders argue you always should. Ethereum co-founder Vitalik Buterin made that case bluntly in a March 15, 2026 post on X:
“running a node is this oh so scary devops task that it is ok to leave to professionals. IT IS NOT… Running your own Ethereum infrastructure should be the basic right of every individual.”
The principle is sound — self-verification is the point of decentralization. But be clear-eyed about the tradeoff: a managed endpoint is convenient, yet it does not give you the same operational control, peer-to-peer participation, privacy, method availability, or verification independence as running your own node, as Ethereum’s nodes-as-a-service docs point out. Many teams start with a provider for speed, then bring nodes in-house as needs grow.
Conclusion
The three setups aren’t rivals — they’re answers to different questions. A full node gives independent validation of current state at a workable size, an archive node preserves historical state for anyone who reads deep history, and a light client trades scope for speed on constrained devices. Match the setup to what your app actually queries and you avoid paying for data you’ll never touch.
Whether you self-host or use a provider, the deciding question stays the same: how far back does your app need to see, and how much do you want to verify yourself? Answer that honestly — and account for the client, sync mode, and pruning behind any storage estimate — and the right node type picks itself.
FAQ
What is the main difference between full and archive nodes?
A full node serves current state and applies full consensus rules, while an archive node additionally retains historical state so it can answer past-state queries directly. Both validate the chain when correctly configured; the archive node trades extra storage for immediate historical reads.
Which is better?
Neither is better in the abstract — they answer different questions. An archive node’s extra cost (roughly 2 TB, or up to ~6.5 TB on Geth with historical trie data) is only worth it if you query historical state; otherwise a full node does the job for less.
How much disk space does a full need?
It depends on the execution client, consensus client, sync mode, and pruning, so there’s no single number. Geth’s hardware guide recommends a 2 TB+ SSD as a planning baseline; confirm current occupied space against a dated benchmark for your exact setup.
Is a pruned Bitcoin node?
Yes. A pruned Bitcoin node validates the entire chain during initial sync and only deletes older raw block data afterward, so it stays fully validating. Bitcoin has no separate “archive node” mode in the Ethereum sense.
What is a light used for?
Light clients power wallets and apps on phones and low-resource devices. On Ethereum they track authenticated consensus headers and request proofs on demand instead of storing the whole chain — Helios, for instance, reports syncing in about two seconds under its tested conditions.
Can a full become an archive?
Usually not without a resync, because discarded historical state can’t be recreated instantly. The exact path depends on the client and database mode, so check your client’s documentation before assuming a migration exists.
Which node type is best for a block explorer or analytics tool?
An archive configuration, since those products depend on historical state. Past account and contract values are things only retained historical state can serve directly.
Do I need to run my own?
Only if control, privacy, or full independence matter to you. Many teams reach full or archive nodes across 120+ networks through a provider like NOWNodes, trading some independence for speed of delivery.
