Hot Nodes vs. Archive Nodes on Solana

If you've ever called getTransaction on a week-old signature and gotten an error back, you've hit the hot-node / archive-node boundary. It's the most common source of confusion when switching RPC providers, and it's worth understanding before you design around a provider's limits.

The Short Answer

A hot node stores recent blockchain state and serves it fast. An archive node stores the full transaction history back to genesis and serves it slower and at much higher cost. Most RPC providers — Nodius included — run hot nodes, because that's what almost every production workload actually needs.

Why the Distinction Exists

Solana produces a block roughly every 400 milliseconds. The full ledger history is measured in hundreds of terabytes and grows constantly. Storing and indexing all of it is a fundamentally different (and more expensive) infrastructure problem than keeping up with the tip of the chain.

So the ecosystem split into two tiers:

Hot nodes keep recent state — current account data, recent blocks, recent transactions — in fast local storage. They answer getBalance, getAccountInfo, simulateTransaction, and sendTransaction in single-digit milliseconds.
Archive nodes (and archive services like BigTable-backed providers) retain everything. They answer historical queries like getTransaction on an old signature, or getBlock for a slot from last month.

What a Hot Node Covers

For the vast majority of real workloads, recent state is all you need:

Workload	Needs archive?
Trading bot reading account state and sending transactions	No
Wallet checking balances and recent activity	No
MEV searcher simulating and landing bundles	No
AI agent monitoring a program's accounts	No
Dashboard showing the last few hours of blocks	No
Block explorer showing any transaction ever	Yes
Tax / audit tooling pulling a wallet's full history	Yes
Forensic analysis of old transactions	Yes

If your workload is in the first group, a hot node is the fastest, most cost-effective tool for the job — and it's exactly what these workloads are built to run on.

How Nodius Handles Retention

Nodius is engineered as a hot node on purpose. Recent blocks and transactions are served straight from local hot retention — getBlock-family methods cover roughly the last few hours of chain history, returned in single-digit milliseconds because the data never leaves fast local storage. That focus is exactly what makes the hot path fast.

For the rare query that falls outside that window, the behavior is clean and predictable: historical / enriched methods that exist specifically for archive data — getEnrichedTransaction, explainTransaction, and similar — return a defined -32004 at no charge. You get an immediate, honest signal to route that one lookup to an archive service, keeping your hot path fast and your costs explicit.

This is a deliberate design choice, and it's the reason the service is fast and cheap where it counts. Every workload in the first table above runs entirely on the hot path — for those workloads, Nodius is the optimized, purpose-built option.

The Practical Rule

When you evaluate an RPC provider, ask one question: does my workload ever touch data older than a few hours?

No → a hot-node provider like Nodius is the right call. This is the common case, and it's where you optimize for latency, reliability, and per-call cost.
Yes, occasionally → run the hot path on a fast hot node (Nodius), and send the rare historical lookup to an archive service. Most teams end up here, and it's the cheapest, fastest setup.
Yes, constantly → your workload is genuinely archive-grade, and you should expect archive-grade pricing.

Splitting the workload this way — fast hot node for the 99% of calls that touch recent state, archive for the 1% that don't — is almost always cheaper and faster than paying one provider to do both.