What is a Solana archive node, and when do you actually need one?

Do you actually need archive access?

Before you provision anything, answer one question: does your workload read data older than what a standard node retains?

A regular Solana RPC node keeps a recent window of ledger data and prunes older slots to stay within disk and memory budgets. An archive node keeps the full ledger history, so requests for old blocks, old transactions, and historical account states still resolve. That difference is invisible to most apps and decisive for a few.

Use this quick test:

If you landed in the "No" column, a standard RPC endpoint is cheaper and simpler. If you landed in "Yes" or "Usually yes", keep reading: the rest of this page is about connecting to archive data without overpaying for it.

What "archive" means on Solana

Solana does not expose a single flag called "archive mode" the way some EVM clients do. In practice, archive access means the node retains ledger history far enough back that historical queries succeed instead of returning an error or an empty result.

Two things matter for your integration:

• Retention depth. How far back the node can serve data. A node that keeps a few days is not archive; one that keeps the full ledger is.
• Query surface. Which methods can reach that history. On Solana this is mostly the getBlock, getTransaction, getSignaturesForAddress, and related methods, plus account-state lookups at historical slots where supported.

When a node has pruned the data you asked for, you typically get an error such as a block-not-available response rather than a silent wrong answer. That error is your signal that the endpoint you are using is not archive-capable for that slot.

Connecting to archive data

You have three practical options, and they differ mainly in control, cost, and how much you want to operate.

OnFinality provides Solana RPC through its RPC API service and dedicated node infrastructure through dedicated nodes. For a shared endpoint you can start with the public Solana endpoint and move to a dedicated archive node when your historical read volume grows.

The public Solana endpoint is:

https://solana.api.onfinality.io/public
wss://solana.api.onfinality.io/public-ws

See the Solana network page for chain details, and RPC pricing for plan options. Public endpoints are fine for testing, but they are shared, so treat them as a starting point rather than a production archive backend.

Request patterns for historical data

Solana's JSON-RPC is a little different from EVM chains: most calls are POST requests with a JSON body, and many methods take a slot or a commitment level. A minimal historical lookup looks like this:

curl https://solana.api.onfinality.io/public \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getBlock",
    "params": [
      250000000,
      {
        "encoding": "json",
        "maxSupportedTransactionVersion": 0,
        "transactionDetails": "signatures",
        "rewards": false
      }
    ]
  }'

A few practical notes that save time:

• Set maxSupportedTransactionVersion. Without it, blocks containing versioned transactions can fail. Pass 0 unless you specifically need another version.
• Trim the response. transactionDetails: "signatures" and rewards: false cut payload size dramatically when you only need an overview.
• Batch where possible. If your client supports JSON-RPC batching, group historical reads to reduce round trips.
• Expect gaps. If a slot is older than the node's retention, you get an error. Handle it explicitly rather than retrying forever.

For account history and signatures, getSignaturesForAddress is usually the entry point, then you fetch individual transactions by signature.

Production readiness checklist

Archive workloads fail in predictable ways. Run through this before you move traffic:

1. Confirm retention depth. Ask how far back the endpoint serves data and whether that matches your oldest required slot.
2. Test your oldest query. Pick a slot near the edge of your required range and verify it returns data, not an error.
3. Check payload limits. Large historical responses can hit response-size or timeout limits. Test with realistic block sizes.
4. Plan for rate limits. Shared endpoints throttle. If your backfill is bursty, size for it or use a dedicated node.
5. Add failover. Point at more than one endpoint and switch on repeated errors.
6. Monitor error classes. Separate "not found / pruned" errors from "rate limited" and "timeout" errors; they need different fixes.
7. Rehearse a backfill. Run a small historical replay end to end before you depend on it.

If you cannot answer items 1 and 2 confidently, that is the gap to close first.

Build versus buy for archive access

Running your own Solana archive node is possible, but the ledger is large and growing, and keeping it healthy is ongoing work: disk provisioning, snapshot handling, upgrades, and monitoring. For a team whose product is not node operations, that is usually a poor use of engineering time.

The tradeoff looks like this:

For most indexers and analytics teams, a managed archive endpoint or a dedicated node is the faster path. Self-hosting makes sense when you have strict data-locality requirements or already run node infrastructure at scale.

Evaluating a Solana archive provider

When you compare providers, do not just compare headline price. Compare what happens under your actual workload.

OnFinality appears first here because it is the option this page is written around: it offers Solana RPC via a managed RPC API and dedicated nodes for heavier workloads. Compare it against your other candidates on the criteria above rather than on marketing claims. For a broader framework, see how to choose an RPC provider.

Common failure modes and fixes

Most of these are configuration or endpoint-choice problems, not data problems. Fix the endpoint and request shape before assuming the data is gone.

Key Takeaways

• A Solana archive node retains full ledger history; a standard node prunes older slots.
• Most apps do not need archive access; indexers, analytics, audits, and backfills usually do.
• "Archive" on Solana is about retention depth and which methods can reach old slots, not a single flag.
• Test your oldest required slot before committing to an endpoint.
• Managed archive RPC or a dedicated node is usually faster to ship than self-hosting.
• Evaluate providers on retention, method support, limits, failover, and observability.

Frequently Asked Questions

Is a Solana archive node the same as a full node? Not exactly. A full node can still prune old data. An archive node keeps history far enough back to serve old blocks and transactions, which is the property you actually care about.

How do I know if my endpoint is archive-capable? Query a slot near the edge of your required range. If it returns data, the endpoint reaches that far back. If it returns a block-not-available error, it does not.

Can I use the public OnFinality Solana endpoint for archive queries? You can use it to test. For sustained historical reads or backfills, use a managed plan or a dedicated node so shared rate limits do not interrupt long jobs.

Do I need WebSocket for archive data? Usually not. Archive access is mostly request/response. WebSocket subscriptions are more relevant to live slot and account monitoring.

What is the biggest mistake teams make? Assuming any RPC endpoint can serve old slots. Retention differs, so test before you migrate.

Next steps

Start by testing your oldest required slot against a candidate endpoint. If it resolves, you can likely use a shared archive-capable RPC plan. If your backfills are large or continuous, look at a dedicated node so your historical reads are not competing with other traffic.

Review Solana network details, compare RPC pricing, and browse supported RPC networks if you also need other chains. When you are ready to move production traffic, a short evaluation against the checklist above will tell you whether a managed endpoint or a dedicated archive node is the right fit.