What is an Avalanche archive node and when should you use one?

Quick recommendation: archive vs pruned vs managed

Before you provision hardware or sign up for a service, decide which data retention mode your workload actually needs. AvalancheGo supports three modes: archive, pruned, and state sync. The table below summarizes the tradeoffs.

If you only need current balances, transaction receipts, or event logs from the last few days, a pruned or state-synced node is sufficient. If you need to query historical state at any past block, or re-execute transactions for analytics, you need an archive node.

Running an archive node yourself means managing multi-terabyte storage, ongoing sync, and backups. For many teams, a managed RPC provider that offers Avalanche archive endpoints is the faster path. OnFinality provides dedicated and shared RPC access to Avalanche networks; check the supported RPC networks page for current availability.

What is an Avalanche archive node?

An Avalanche archive node is an AvalancheGo node configured to keep the complete history of the chains it tracks. Unlike a pruned node, which discards old state to save disk space, an archive node retains every historical state, allowing you to query the state of any address or contract at any point in time.

Avalanche's primary network consists of three built-in blockchains: the C-Chain (Ethereum-compatible), the X-Chain (asset transfers), and the P-Chain (platform and validators). Each chain can have its own data retention mode. For example, you might run the C-Chain in archive mode for historical Ethereum-style queries, while keeping the X-Chain and P-Chain pruned.

Archive nodes are essential for:

• Auditing and compliance: proving the state of an account or contract at a past block.
• Analytics and indexing: building historical datasets for dashboards, DeFi analytics, or The Graph subgraphs.
• Backtesting trading strategies: replaying historical market conditions.
• Debugging: tracing a transaction's full execution path.

How Avalanche archive nodes differ from pruned and state-synced nodes

AvalancheGo's data retention is configured per chain. The three modes are:

• Archive: keeps all historical state and blocks. Enables queries like eth_getBalance at an old block number, or eth_getLogs over a wide historical range.
• Pruned: keeps only the most recent state and blocks. Old state is deleted after a certain period. This reduces disk usage but limits historical queries.
• State sync: downloads a state summary and syncs only the latest state, skipping historical blocks. This is the fastest way to get a node running, but it offers the least historical data.

You can mix modes across chains. For example, a node might use state sync for the P-Chain and X-Chain, but archive for the C-Chain.

When to run your own Avalanche archive node

Running your own archive node gives you full control over data, access, and cost—if you have the operational capacity. Consider this path if:

• You need to query historical state frequently and have predictable, high-volume workloads.
• You require data sovereignty or want to avoid third-party dependencies.
• You have the infrastructure expertise to manage a multi-terabyte database, handle backups, and monitor sync health.

Key operational considerations:

• Storage: Archive nodes require significant disk. Plan for terabytes, and use fast SSDs for the database.
• Sync time: Initial sync can take days or weeks, depending on network speed and hardware. State sync can speed up catch-up, but you'll need to enable archive mode from the start to retain history.
• Backups: Regular backups are critical. AvalancheGo's backup and restore documentation covers backing up your node ID and database.
• Monitoring: Track sync status, disk usage, and API response times. Set up alerts for anomalies.

When to use a managed Avalanche archive RPC provider

Most teams do not need to run their own archive node. A managed RPC provider handles infrastructure, scaling, and maintenance, letting you focus on building. Consider a managed service if:

• You want to start querying historical data quickly without waiting for a multi-day sync.
• You need high availability and failover without managing your own cluster.
• You prefer predictable pricing over hardware and operational costs.

OnFinality offers RPC services for Avalanche and many other networks. You can get an API key and start making requests in minutes. See RPC pricing for plan details and the supported networks page for Avalanche endpoint availability.

How to configure an Avalanche archive node

If you decide to run your own node, here's a high-level configuration approach. AvalancheGo uses a JSON config file per chain. For the C-Chain, create a config file at configs/chains/C/config.json with the following content:

{
  "pruning-enabled": false
}

Setting pruning-enabled to false disables pruning and keeps full archive data. For the X-Chain and P-Chain, you can create similar config files if you want archive mode for those chains as well.

When starting AvalancheGo, point to your config directory with the --chain-config-dir flag. A minimal systemd service file might look like:

[Unit]
Description=Avalanche Node
After=network.target

[Service]
User=avalanche
WorkingDirectory=/opt/avalanche
ExecStart=/opt/avalanche/build/avalanchego \
  --chain-config-dir=/opt/avalanche/configs/chains \
  --db-dir=/var/lib/avalanche/db \
  --http-host=0.0.0.0 \
  --http-port=9650 \
  --network-id=mainnet
Restart=on-failure
LimitNOFILE=1000000

[Install]
WantedBy=multi-user.target

After starting the node, you can query it via JSON-RPC. For example, to get the latest block number on the C-Chain:

curl -X POST http://localhost:9650/ext/bc/C/rpc \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'

Common pitfalls when running an archive node

• Underestimating disk space: Archive nodes grow quickly. Monitor disk usage and plan for expansion.
• Incorrect config path: Ensure the chain config directory is correctly specified. A common mistake is placing the config file in the wrong location.
• Forgetting backups: Losing an archive node means losing historical data. Set up automated backups.
• Not monitoring sync health: A node that falls behind can serve stale data. Use metrics and alerts.
• Ignoring network requirements: Archive nodes need stable, high-bandwidth connections. Check your firewall and bandwidth.

How to query historical data on an Avalanche archive node

With an archive node, you can query historical state using standard Ethereum JSON-RPC methods on the C-Chain. For example, to get the balance of an address at a specific block:

curl -X POST https://your-endpoint \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0x...", "0x123456"],"id":1}'

The second parameter is the block number in hex. You can also use eth_getLogs to query historical event logs over a block range.

For JavaScript developers using ethers.js:

const { ethers } = require("ethers");

const provider = new ethers.JsonRpcProvider("https://your-endpoint");

async function getHistoricalBalance(address, blockNumber) {
  const balance = await provider.getBalance(address, blockNumber);
  console.log(`Balance at block ${blockNumber}: ${ethers.formatEther(balance)} AVAX`);
}

Key Takeaways

• An Avalanche archive node stores complete historical state, enabling queries that pruned nodes cannot answer.
• Choose archive mode only if you need historical data; otherwise, pruned or state sync is more cost-effective.
• Running your own archive node requires significant storage, sync time, and operational effort.
• Managed RPC providers like OnFinality offer Avalanche archive endpoints, reducing infrastructure overhead.
• Always monitor disk usage, sync health, and backups to avoid data loss.

Frequently Asked Questions

What is the difference between an archive node and a pruned node on Avalanche?

An archive node keeps all historical state and blocks, while a pruned node deletes old data to save disk space. Archive nodes allow queries at any past block, while pruned nodes only serve recent data.

How much storage does an Avalanche archive node need?

Storage requirements vary by chain and network activity. The C-Chain archive can be several terabytes. Plan for large, fast SSDs and monitor growth.

Can I run an archive node for only the C-Chain?

Yes. AvalancheGo allows per-chain configuration. You can set pruning-enabled to false for the C-Chain while keeping other chains pruned.

Is it cheaper to run my own archive node or use a managed provider?

It depends on your workload. Running your own node involves hardware, electricity, and maintenance. Managed providers offer predictable pricing and lower upfront effort. Compare costs based on your query volume.

Does OnFinality provide Avalanche archive nodes?

OnFinality offers RPC services for Avalanche networks. Check the supported networks page for current archive endpoint availability and pricing for plan details.