Best RPC provider for indexers

A normal dApp usually follows user traffic. An indexer follows chain history.

That means indexers often generate:

• sustained RPC method volume
• large eth_getLogs ranges
• historical block reads
• archive state calls
• backfills after deployment changes
• retries after provider errors
• reprocessing after bugs or schema changes
• multi-chain synchronization pressure

This makes the RPC provider part of the data pipeline, not just an external API.

There is no best endpoint independent of the indexer's output contract. Start by recording the chains, methods, oldest required blocks, confirmation policy, sustained and backfill rates, transport, response sizes, and recovery objective. A log indexer, trace indexer, portfolio indexer, and block explorer can need different data from the same chain.

Turn those needs into hard gates before comparing latency or price. A candidate is disqualified if it cannot serve a required chain-method-block combination, if its fallback loses that capability, or if its limits prevent the indexer from meeting the catch-up objective. Archive state, receipt and log history, historical proofs, and trace namespaces must be tested separately; the archive RPC decision guide explains why one archive label cannot prove all four.

Only score providers that pass the capability gates. This prevents a fast current-state endpoint or a low headline estimate from winning an evaluation it cannot complete.

1. Reliable eth_getLogs and historical reads

For many indexers, eth_getLogs is the core method. Test narrow and wide topic filters, dense and sparse contracts, recent and historical ranges, response-size limits, adaptive range behavior, and realistic concurrency. An old block lookup does not prove old state or receipt retention, so probe each required data class independently.

2. Data correctness and reorg recovery

A provider should return block number, hash, parent hash, transactions, receipts, and logs consistently enough for the indexer to verify its own cursor. The Ethereum `eth_getLogs` specification exposes block and transaction identity plus a removed flag, but the application still needs idempotent writes and a rollback path. Store the committed block number and hash, detect parent-hash discontinuity, and replay from the common ancestor.

Treat null and empty arrays according to method semantics rather than rotating providers blindly. Compare hashes at a common block when freshness or fork disagreement matters. A provider cannot remove the indexer's responsibility for canonical data.

3. Sustained throughput and catch-up time

Measure useful blocks or events committed per minute, not only requests per second. Separate live traffic from backfills and test the time required to recover a realistic outage. Record p50, p95, p99, timeouts, 429s, response bytes, range reductions, and retry amplification. A provider that keeps up at the head but cannot close a backlog may fail the real service objective.

4. Capability-preserving failover

Force the preferred path out of service and repeat the oldest-state, log, receipt, and trace tests. The secondary must satisfy the same history, method, tracer, freshness, and response-shape requirements. The RPC failover guide covers block pinning and stale-upstream checks.

5. Predictable cost and operational support

Model normal sync, backfill, reprocessing after a schema change, and an incident month from the same method mix. Include retries and failed work. Then record who owns client upgrades, lag, corruption, capacity, and provider escalation, plus the response time available when the indexer falls behind.

SolidRPC is designed for heavy EVM workloads, including indexers and data pipelines. On selected networks it operates full or archive nodes behind method- and history-aware routing, while Dwellir supplies external fallback and chains or capabilities not served by the operated fleet. The current network catalog defines archive, debug_*, and Parity-style trace_* support per chain.

Its plans use response quotas rather than method-weighted compute units, and supported archive routes do not carry a separate archive surcharge. The service currently exposes HTTPS JSON-RPC rather than WebSockets. An indexer that requires subscriptions must keep another transport or use polling with a durable cursor; Geth's subscription documentation also notes that subscriptions deliver current rather than past events and disappear with the connection, so a range backfill remains necessary after disconnects.

SolidRPC manages node health, routing, upgrades, and recovery for the service boundary. The customer still owns filter correctness, idempotent storage, block-hash cursors, reorg rollback, and application-specific completeness checks. Evaluate it with the same pass/fail matrix as any provider rather than assuming operated nodes eliminate pipeline work.

Use a benchmark that matches the indexer and produces an auditable dataset:

1. Freeze a matrix of real chains, contracts, methods, tracers, block ranges, and expected results.
2. Include sparse and dense intervals, the oldest required block, current sync, and a bounded backlog.
3. Establish the canonical block hashes and known event counts for verification samples.
4. Run at realistic concurrency with one total deadline and a bounded retry budget.
5. Record every attempt's endpoint, latency, outcome, bytes, range, and returned block identity.
6. Measure committed blocks or events per minute, p50/p95/p99, timeout and 429 rate, retries, and head distance.
7. Disable the preferred upstream and repeat the capability and correctness samples.
8. Restart the worker mid-page and confirm that idempotent writes plus the durable cursor create neither gaps nor duplicates.
9. Inject or replay a reorg scenario and verify rollback to the common ancestor.
10. Price the same completed workload under normal, backfill, and failure conditions.

Run long enough to expose throttling, cache effects, and degradation. The gap-free `eth_getLogs` backfill guide provides the paging and cursor design for log-driven benchmarks.

Apply hard gates first, then score the survivors with weights that reflect the product. A practical scorecard is:

• Capability: every required chain, method, tracer, transport, and oldest block passes on the normal and failover paths. Hard gate.
• Correctness: known results match, block identities are coherent, valid empty results are preserved, and reorg drills are recoverable.
• Live throughput: the indexer stays within its permitted head distance at sustained load.
• Backfill recovery: the measured catch-up rate meets the recovery objective without starving live traffic.
• Reliability: timeout, 429, stale response, and retry rates stay within predeclared thresholds.
• Cost predictability: normal, backfill, and incident estimates use the same completed workload and include retries.
• Operations and support: ownership, escalation, change notice, and recovery expectations are explicit.
• Portability: the application can export data, preserve its cursor, and move a workload without depending on a proprietary response shape.

Do not hide a failed hard gate inside a weighted average. Publish the test inputs, thresholds, raw observations, and date; client versions, provider policies, and chain support change, so a provider selection is evidence for a point in time rather than a permanent ranking.

For indexers, RPC is data infrastructure. Choose a provider based on logs, archive behavior, throughput, retries, failover, support, and cost predictability.