Alchemy alternatives for archive RPC

A normal dApp may mostly call current block data. An indexer, explorer, analytics pipeline, or trading infrastructure system behaves differently. It may repeatedly query historical ranges, retry failed calls, run backfills, request older state, or process logs across millions of blocks.

That creates three problems:

1. Cost predictability Method-weighted billing can be hard to forecast when the workload shifts from light reads to archive, logs, traces, or retries.
2. Rate-limit behavior Some providers look fine during normal traffic but become painful when backfills, retries, or old block reads begin.
3. Operational ownership If the provider cannot handle the workload reliably, your team ends up building fallback routing, retry logic, monitoring, and provider switching anyway.

Start with the reason for evaluating an alternative. If the application depends on Alchemy-specific enhanced APIs, webhooks, Smart WebSockets, account abstraction, or transaction tooling, moving every request to a basic JSON-RPC endpoint can create more engineering work than it removes. Alchemy's current pricing-plan documentation lists archive data across its plans, while Debug and Trace APIs are plan-dependent. Compare the exact feature and plan rather than assuming the brand either includes or excludes every archive workflow.

A change is more defensible when the problem is concentrated in a measurable RPC class: sustained eth_getLogs backfills, old-state reads, trace/debug volume, throughput errors, or compute-unit variance. In that case, choose among four operating models:

• Keep one general developer platform: simplest when its APIs, transport, support, and billing already fit the whole application.
• Split heavy JSON-RPC from enhanced APIs: keep the product-specific services and route archive, logs, or traces through a qualified RPC specialist. This reduces migration scope but adds routing and two vendor relationships.
• Buy dedicated or reserved capacity: useful when isolation or a contractual throughput floor matters; verify whether the fallback has the same history and methods.
• Self-host or run a hybrid fleet: gives the most client and data control, while making upgrades, storage, monitoring, and recovery your responsibility.

Do not migrate because one monthly total looks high. Export the method, chain, outcome, retry, and time-of-day mix first, then identify which calls or limits actually create the cost or reliability problem.

Archive availability

Check whether archive access is included, gated by plan, limited by chain, or subject to special method behavior. “Supports archive” is not enough. Test the exact state method and oldest block you need. Old blocks, receipts, logs, historical state, proofs, and traces depend on different retained data; the archive-node decision guide maps those requirements.

Heavy method and transport support

Run realistic tests for:

• eth_getLogs
• historical eth_call
• debug_traceTransaction with the required tracer
• Parity-style trace_block when required
• old block and receipt reads
• HTTPS batches or WebSocket subscriptions used by the application

Do not benchmark only eth_blockNumber. It proves the endpoint is reachable, not that it can support the production workload. Confirm support per chain: an archive route can expose debug_* without exposing trace_*, and an HTTPS-only alternative is not a drop-in replacement for a WebSocket consumer.

Pricing and throughput model

Alchemy's official compute-unit documentation explains that methods carry different CU weights and throughput is measured in CUs per second. Translate the traffic export into the current provider unit, including errors and retries, then model normal sync, backfill, and incident months separately. Compare cost per successfully completed workload, not per advertised request.

Failure handling and support

Ask what happens when a node lags, a client fails, a database becomes corrupted, or a chain-specific upgrade breaks behavior. Require the fallback to pass the same method, history, freshness, and response-shape tests as the preferred path. Record who owns the incident, the escalation target, and the recovery objective before production traffic moves.

SolidRPC replaces the provider pool used for portable HTTPS JSON-RPC. Applications call one SolidRPC endpoint; SolidRPC owns upstream diversity, capability routing, failover, monitoring, and recovery behind it. The current network catalog is the source of truth for archive, debug_*, and trace_* availability on each chain.

The commercial model uses response quotas instead of method-weighted compute units, with one response unit per completed method call and no separate archive surcharge on supported routes. SolidRPC currently serves HTTPS JSON-RPC rather than WebSockets. Alchemy-specific enhanced APIs, webhooks, or account-abstraction products are separate product dependencies, not fallback RPC lanes.

A team can qualify one read-only workload first, expand through the required chain and method matrix, then retire its old provider router after the new route meets correctness, throughput, and recovery gates. The intended production state for portable JSON-RPC is one SolidRPC integration.

Use your own workload and define pass/fail gates before seeing the results. A fair test should include:

• every required chain, method, tracer, transport, and oldest block
• real dense and sparse block ranges
• live sync, peak sustained traffic, and a bounded backfill
• cold and warm queries
• timeout, 429, stale-head, and provider-failover drills
• response-shape and block-hash consistency checks
• retry traffic and total end-to-end completion time
• cost for the same successful method mix in normal, backfill, and failure months

Shadow production traffic before cutover, without submitting writes twice. Compare p50 and tail latency, useful completion rate, head freshness, recovery behavior, and operational ownership. An alternative fails the evaluation if a required method or historical block disappears after failover, even when its average latency or estimate is lower.

1. Export 28 to 30 days of calls by chain, method, status, retries, response bytes, and time window.
2. Separate required Alchemy platform features from portable JSON-RPC traffic.
3. Mark the oldest state, block, receipt, log, proof, and trace each workload needs.
4. Record HTTPS, batch, WebSocket, webhook, SDK, and enhanced-API dependencies.
5. Build the current cost baseline from Alchemy's live CU and plan tables.
6. Set pass/fail thresholds for freshness, correctness, throughput, 429s, timeouts, and recovery.
7. Replay a representative live-sync and backfill workload against each candidate.
8. Force preferred-upstream failure and repeat the archive and trace tests.
9. Shadow one read-only workload, then migrate it with a bounded rollback path.
10. Keep application-level reorg handling, idempotent writes, and durable cursors regardless of provider.

The decision is complete only when the replacement serves the same required output—not merely the same method name—and the team knows which system owns every feature left behind.

Alchemy is a strong platform, but archive-heavy teams should evaluate alternatives based on workload economics and operational reliability. If your real pain is cost uncertainty, archive reads, traces, logs, backfills, or managing provider limits, you need a provider designed around heavy RPC workloads.