Alchemy vs QuickNode vs Chainstack vs dRPC vs Tenderly: How to Compare

The headline number on an RPC provider’s free tier is the least useful thing on the page. Two providers advertising the same monthly allowance can differ by an order of magnitude in how much of your actual workload they serve, because the allowance is consumed by weighted units rather than by requests, and the weights differ per method. A workload heavy in debug_traceTransaction and a workload heavy in eth_getBalance will exhaust the same nominal allowance at completely different rates.

So the comparison that matters is not which number is biggest. It is how each provider meters, what it covers, and what happens when you cross the line. Those three things are stable enough to reason about, while published limits change often enough that any number written in an article is provisional by the time you read it.

• Metering models are not comparable across vendors. Compute units, credits and flat request counts weight methods differently.
• Method coverage and archive depth are decided at the node, and no layer above can add them back.
• Network coverage varies more than marketing pages suggest, especially outside the major EVM chains.
• The only reliable comparison is replaying a sample of your own traffic against each candidate.

Why the Headline Number Misleads

Most providers meter in a synthetic unit rather than in requests. A simple balance read costs a little, a log query over a wide block range costs more, and a trace call can cost a great deal more. The weights are published, but they are published per method in a separate table from the plan comparison, which is where the mismatch hides.

The practical consequence is that the allowance tells you nothing until you know your method mix. An indexer doing wide eth_getLogs scans and a wallet backend doing balance lookups will consume the same headline allowance at rates that differ by more than a factor of ten.

Rate limits compound this. A monthly allowance describes volume; a per-second limit describes burst tolerance. Plenty of workloads have adequate monthly headroom and still fail during a traffic spike, because concurrency rather than volume was the binding constraint. Both numbers matter and they constrain different failure modes, as covered in handling RPC rate limits and 429 errors.

Axis One: The Metering Model

Compute-unit and credit models weight per method, which is fairer to light workloads and much harder to forecast. If your traffic mix shifts, so does your bill, and the relationship is not linear. Teams running trace-heavy or log-heavy workloads consistently report that these models cost more than a naive request count would suggest.

Flat request-count pricing is easier to predict and less favorable to light calls, since a cheap read consumes the same allowance as an expensive one. For workloads dominated by simple reads, this frequently works out cheaper in practice despite looking worse on paper.

The question worth asking before you commit: can I forecast next quarter’s bill from this quarter’s traffic without building a model? If the answer is no, that is a real operational cost, and it belongs in the comparison alongside the price.

Axis Two: Method Coverage and Archive Depth

This is where a bad choice becomes expensive, because it cannot be fixed at any layer above the node. Whether debug_ and trace_ namespaces are enabled, how far back archive queries reach, and whether they are available on your plan at all are decided by the provider’s node configuration.

Archive access in particular is often gated to higher tiers or offered with limited depth, and the limit is discovered mid-integration rather than during evaluation. If your application reads historical state — reconciliation, analytics, anything replaying past blocks — verify the actual depth on the actual plan before building against it.

No gateway, cache or routing layer compensates for a missing method. As Aurpay’s gateway documentation puts it for its own product, a supported network means traffic can be routed there, not that every upstream implements every method; the gateway does not emulate node capabilities. That is true of the category generally, and it is why coverage belongs at the top of your evaluation rather than the bottom.

Axis Three: Network Coverage

Marketing pages tend to quote a large chain count. What matters is whether your specific chains and networks are covered, including testnets, which are frequently missing where the mainnet is supported.

There is a usefully concrete data point here. Aurpay’s RPC Gateway can import endpoint inventory from five vendors, and its documentation records how much of its own 20-combination table each vendor actually covers: Alchemy and QuickNode cover all 20, Chainstack covers 19 with Litecoin Testnet excluded, dRPC covers 16 and never produces a native HTTP API endpoint, and Tenderly covers 10 EVM combinations only. That is a comparison drawn from an integration rather than from marketing copy, and the shape it reveals is typical — coverage converges on the major EVM chains and diverges sharply on Bitcoin-family chains, Solana and TRON.

If your stack is Ethereum plus a couple of L2s, nearly everyone covers you and this axis barely matters. If you need Bitcoin, Litecoin, TRON or the TRON native HTTP API alongside EVM chains, the field narrows quickly, and it narrows further on testnets.

Axis Four: What Happens at the Ceiling

Providers behave differently when you cross a limit, and the difference matters more than the limit itself.

Some throttle, returning a rate-limit response and continuing to serve at a reduced rate. Some hard-stop until the period resets. Some auto-upgrade and bill the overage. From an availability standpoint these are very different events, and only the first degrades gracefully.

There is also a subtlety in how the limit is signalled that catches teams out. If a provider expresses its rate limit as a JSON-RPC error inside an HTTP 200 response rather than as a transport-level 429, then any gateway in front of it will treat the call as a successful forward and will not fail over to your secondary. Aurpay’s failsafe documentation is explicit that a valid upstream JSON-RPC error is returned verbatim with no retry and no failover. So a provider’s choice of signalling convention directly determines whether your redundancy engages. It is worth testing rather than assuming, and the mechanics are covered in RPC failover and circuit breaking.

The Five, Briefly

Characterizations rather than numbers, because the numbers move. Verify current limits on each provider’s own pricing page before deciding.

Alchemy

Alchemy pairs RPC access with a developer tooling suite and meters in compute units. Broad network coverage. The tooling is the differentiator, and it is genuinely useful if you will use it; if you only need raw RPC you are paying for surface you will not touch.

QuickNode

QuickNode targets throughput-heavy workloads with broad network and archive coverage, metered in credits. Strong where request volume is the constraint. Like any weighted model, forecasting requires attention.

Chainstack

Chainstack covers nearly the same network surface and positions around multi-region infrastructure and dedicated nodes. A reasonable fit when deployment topology matters to you.

dRPC

dRPC routes across a distributed set of node operators and offers public endpoints alongside authenticated access. Cost-effective, with the trade-off that latency varies more because traffic transits third-party operators. Its coverage gap on native HTTP API endpoints matters only if you need TRON’s REST-style interface.

Tenderly

Tenderly extends a simulation and observability platform into the endpoint layer. If you already use it for debugging and simulation, the RPC is a natural extension. Its EVM-only coverage makes it a poor sole provider for a multi-chain stack.

None of these is a bad product. They are optimized for different constraints, and the right answer follows from which constraint binds you.

How to Actually Run the Comparison

Stop reading pricing pages and replay your own traffic. Capture a representative sample of production RPC calls, including the expensive ones, and issue that sample against each candidate’s free tier. Measure how much allowance it consumed, p95 latency, and error rate. This is a day of work and it settles the question in a way that no comparison table can, because it prices your method mix rather than a generic one.

While you are there, test the ceiling behavior deliberately. Push past the limit and record what comes back: the HTTP status, the error code, whether a Retry-After is present, and whether the limit arrives at the transport layer or inside a 200 response. That last detail determines whether your failover works, and it is not documented on any pricing page.

Then test archive depth against your actual oldest query rather than the advertised depth, and confirm the namespaces you need are enabled on the tier you plan to buy rather than on the enterprise tier.

Finally, evaluate two providers rather than one, chosen so their failure modes are unlikely to correlate. Two vendors renting from the same cloud region are less independent than they appear. Running both behind a routing layer means the comparison never has to be final, and switching later stops being a migration.

Frequently Asked Questions

Which RPC provider has the best free tier?

The question does not have a general answer, because allowances are consumed by weighted units and the weights differ per method. A provider that is generous for balance reads can be restrictive for trace calls. Replay a sample of your own traffic against each candidate; it is the only comparison that reflects your workload.

Can I just use several free tiers together?

Yes, and it works reasonably well, but it means managing several credentials, several rate-limit behaviors and several failure modes. That maintenance burden is exactly what a routing layer removes, which is why multi-provider setups and gateways tend to arrive together.

Does a gateway or aggregator replace these providers?

No. A gateway operates no nodes and cannot serve data your upstreams cannot serve. It sits in front of providers like these and handles routing, failover and caching. The distinction is worked through in node providers versus gateway layers.

How important is network coverage in practice?

It depends entirely on your chains. For Ethereum and the major L2s, nearly every provider covers you and this axis is close to irrelevant. For Bitcoin, Litecoin, TRON or the TRON native HTTP API, coverage varies substantially, and testnet support varies more than mainnet support.

What is the most common mistake in this evaluation?

Choosing on the headline free-tier number and discovering mid-integration that a required method is not enabled, or that archive depth stops short of where the application needs to read. Verify coverage first; it is the constraint that cannot be worked around later.

Should I test how a provider behaves at its rate limit?

Yes, explicitly. Whether the limit arrives as a transport-level 429 or as a JSON-RPC error inside a 200 response determines whether any failover you configure will engage. It is not on the pricing page and it is trivial to test during evaluation.

Compare on Constraints, Not on Headlines

Verify method coverage and archive depth first, because those cannot be fixed above the node. Then look at the metering model and ask whether you can forecast a bill from it. Then check your specific networks and testnets. Then test the ceiling behavior. The headline allowance is the last thing to look at, not the first.

Whichever providers you land on, running two of them behind a routing layer keeps the decision reversible. The Aurpay RPC Gateway can import endpoint inventory from all five vendors discussed here and route across them from a single API key, with retries, health checks, circuit breaking and a shared cache in front. It is free and open source under Apache-2.0, and it operates no nodes of its own, so it sits alongside your provider choice rather than competing with it.