Polygon archive node RPC provider

You may need archive RPC if your application depends on:

• historical contract state
• old block reads
• backfills
• analytics over long periods
• indexer rebuilds
• historical balance or position calculations
• debug-tracing workflows
• compliance or audit workflows

If your system only reads current state, full node access may be enough. If your system reconstructs history, archive behavior matters. Archive is still not a promise that every method works at every historical block, so test the exact method and depth you require.

Polygon Labs announced that Erigon support for Polygon PoS would end on August 1, 2026 and recommended Bor with PBSS for full archive nodes. The recommended shape uses full sync, archive garbage-collection mode, PebbleDB, path-based state, and zero-value history-retention settings when the operator needs the entire transaction, log, and state history.

That migration changes provider evaluation in two practical ways. First, ask which client and database scheme backs the archive endpoint; an old claim based on Polygon Erigon no longer describes the supported operating path. Second, test methods individually. Bor is geth-lineage, so debug_* methods and Parity-style trace_* methods are different capability families. Polygon Labs also notes that Bor does not yet retain the trie nodes needed for old eth_getProof requests beyond the recent window, even when historical state retention is configured.

A useful provider answer should therefore name the client, retention configuration, supported method family, tested historical depth, and what capability remains after failover.

A Polygon PoS RPC node is a two-client system. Bor executes Polygon blocks and exposes the EVM RPC surface; Heimdall-v2 follows Polygon consensus and supplies Bor with validator spans and state-sync events. Both clients must be synced, peer-connected, upgraded before their respective hard forks, and monitored. A healthy Bor process beside a halted or incompatible Heimdall is not a healthy Polygon RPC node. Polygon's official full-node guide installs and starts both components for that reason.

Capacity depends on retention, database scheme, snapshot size, and growth. Polygon's current prerequisites list 32/64 GB RAM, 8/16 CPU cores, 4/6 TB storage, and 1 Gbit/s for a mainnet full or sentry node. Do not treat those full-node figures—or the same page's legacy Erigon archive row—as a fixed PBSS archive-node quote. For a Bor PBSS archive, size fast SSD or NVMe storage from the current archive snapshot and measured growth, then keep headroom for extraction, database compaction, upgrades, and recovery. Polygon's snapshot guide recommends additional growth buffer and makes clear that Bor and Heimdall data must both be restored.

Before self-hosting, document this minimum operating plan:

• Bor PBSS/PebbleDB archive settings and which transaction, log, and state histories are retained;
• a compatible Heimdall-v2 release and a separately monitored advancing consensus height;
• high-IOPS storage with growth, compaction, and snapshot-extraction headroom;
• public peer connectivity while JSON-RPC, metrics, and Heimdall APIs stay behind controlled access;
• known-good snapshots, checksum and restore steps, plus a measured recovery-time objective;
• alerts for both client heads, peer loss, disk latency and capacity, RPC errors, and historical-method probes;
• a second qualified RPC path for maintenance, client failure, or a full database rebuild.

These requirements are part of the cost comparison. A server that can hold today's database but cannot restore, compact, or fail over under the required recovery target is not production archive capacity.

Shared managed RPC is usually the sensible starting point for development, light application reads, and workloads whose peaks fit a published quota. Dedicated or reserved capacity becomes more defensible when a measured Polygon workload needs sustained backfill throughput, controlled concurrency for debug traces, a contractual capacity floor, network allowlisting, a specific client or retention profile, or isolation from other customers' bursts.

The word “dedicated” is not a complete architecture. It can mean a reserved quota on a shared fleet, an isolated client process, a virtual machine, or a physical server. Ask the provider to state which layer is exclusive, the usable rate and concurrency floor, the Bor and Heimdall topology, archive history, storage runway, upgrade ownership, and recovery target. Then force the dedicated path out of service and repeat the required historical and debug calls against its fallback.

A single dedicated node can be less available than a shared multi-node route because it creates one database and one maintenance window. If the reason for buying dedicated capacity is reliability, require a second independently qualified path rather than assuming tenancy provides redundancy. If the reason is throughput, benchmark useful blocks, logs, or traces completed per minute at the promised floor—not only isolated request latency.

Archive availability by chain and plan

Do not assume archive access is universal. Check whether Polygon archive is included, paid separately, restricted to certain plans, or subject to method limits.

eth_getLogs performance

Polygon workloads often rely heavily on event logs. Test large and realistic ranges rather than only small queries.

Measure:

• latency
• timeout rate
• 429 rate
• consistency
• response size behavior
• retry impact

Historical state reads

If you need state at old blocks, test the exact patterns your application uses. Include any proof methods rather than assuming that archive state makes them available.

Exact debug method support

If your product requires execution traces, confirm the namespace and method instead of asking only whether “tracing” is supported. Test debug_traceTransaction, required tracer options, and real transaction hashes across recent and historical blocks. Do not assume that support for debug_* also means support for Parity-style trace_transaction or trace_block.

Failover capability

Check whether a fallback retains the same archive depth, log behavior, and debug methods. A fallback can keep current reads alive while historical calls fail.

Cost predictability

Polygon archive workloads can involve high RPC call volume, especially during backfills. Estimate cost from real method mix, not average daily RPC calls alone.

SolidRPC is built around predictable-cost RPC for heavy EVM workloads. As of August 4, 2026, its SolidRPC-operated Polygon archive path uses Bor with PBSS/PebbleDB and a Heimdall-v2 sidecar. The public Polygon catalog includes standard JSON-RPC and debug_*, but not Parity-style trace_*. Use debug_traceTransaction when it matches the workload; do not plan a migration around trace_transaction on chain 137.

SolidRPC focuses on:

• a managed Polygon Bor archive path
• predictable response quotas
• logs, historical reads, and supported debug methods
• AI SRE monitoring
• self-operated infrastructure with external failover
• direct engineer support
• migration planning

The goal is to give teams archive RPC without pushing node operations back onto their engineers, while keeping chain-specific method boundaries explicit.

Use a benchmark that includes:

• current and historical block reads
• eth_getLogs over production-like ranges
• old block eth_call if needed
• trace/debug calls if needed
• normal sync and backfill behavior
• retries and error tracking
• cost estimate under peak load

Run tests long enough to observe throttling or degradation. Short tests can miss provider behavior that appears only under sustained load.

Choosing a Polygon archive node RPC provider is not just about whether archive exists. It is about whether the provider can support your real workload predictably.