dRPC vs Alchemy: Metered Compute vs Flat-Rate RPC

June 15, 2026 · 5 min read · #drpc #alchemy #comparison #rpc

If you're comparing dRPC and Alchemy, you've probably already noticed they don't price the same way they market themselves. dRPC sells decentralization and pay-as-you-go; Alchemy sells a polished platform with enhanced APIs. But under the hood they bill you with the same fundamental unit: compute units. Every request costs some number of CUs, the heavy methods cost more, and your monthly bill is the running total.

So the comparison isn't really "which is cheaper per CU." It's two questions stacked on top of each other: between these two metered providers, which fits your workload — and, one level up, does metered compute fit your workload at all? This post answers both.

The two, honestly

Alchemy is the incumbent managed platform. You get a single dashboard, deep observability, and a set of enhanced APIs that go beyond raw JSON-RPC — NFT metadata, token balances, transfer history, webhooks, and the trace/debug methods — all behind one key. Billing is CU-based with a free tier, and the paid tiers unlock higher throughput and the premium method classes. If you want batteries-included tooling and you're building on the chains Alchemy supports, it's a strong, mature product.

dRPC is a decentralized RPC aggregator. Instead of running one provider's nodes, it routes your request across a network of independent node operators, with verification and automatic failover if an upstream is slow or down. Its headline strengths are redundancy (no single backend to take you offline), a very large chain count, and pay-as-you-go pricing with no monthly commitment — you can run on the public endpoints for free and only pay when you need higher limits or guaranteed routing. It's also CU-metered.

Neither is a bad product. They're optimized for different things, and both share the trait that your bill moves with your usage and method mix.

How compute units actually bite

The reason CU pricing is hard to reason about is that not all calls cost the same. A method-cost table looks roughly like this (illustrative — exact numbers differ by provider and change over time):

Method Relative CU cost
eth_blockNumber very low
eth_call low
eth_getBalance low
eth_getLogs high
debug_traceTransaction very high
trace_block very high

The trap is that the methods you call most in production — eth_getLogs for event indexing, traces for analytics — are exactly the expensive ones. A backfill that pages through millions of blocks with eth_getLogs, or an indexer that traces every transaction, runs up CUs fast and unpredictably. We dug into this dynamic in detail for Alchemy's compute units and the equivalent QuickNode API credits; the short version is that the bill tracks your heaviest method, not your average one.

It gets worse with retries. If you page eth_getLogs and hit a range cap, the failed call and the smaller re-queries can all meter. Spiky, read-heavy workloads — the normal shape of an indexer or a bot — are the ones metered compute treats least kindly.

Head to head

Dimension dRPC Alchemy
Billing model Compute units, pay-as-you-go Compute units, tiered plans
Free tier Public endpoints, no commit Generous monthly CU allowance
Architecture Decentralized, multi-provider routing First-party managed nodes
Redundancy Routes around dead upstreams Single provider's fleet
Chain coverage Very broad Broad, curated
Enhanced APIs Mostly raw JSON-RPC NFT, token, transfers, webhooks, trace
Observability Basic Deep dashboards and analytics
Bill predictability Low (usage-driven) Low (usage-driven)

The pattern: Alchemy wins on tooling and enhanced APIs; dRPC wins on redundancy, breadth, and no-commit pricing. They tie on the thing that matters most for a finance team — neither gives you a predictable monthly number, because both scale with usage and method weight.

Where each is the right call

  • Choose Alchemy if you lean on the enhanced APIs — NFT metadata, token/transfer endpoints, webhooks, or trace/debug — and you value a single polished dashboard over squeezing the last dollar out of per-call cost. The tooling is the product.
  • Choose dRPC if your priority is uptime through redundancy, you need a long-tail chain that managed providers don't carry, or your usage is low and bursty enough that pay-as-you-go means you pay almost nothing when idle.

That second case is the genuine sweet spot for metered compute: low or spiky usage. If you fire a few thousand calls a day, pay-as-you-go is close to free, and committing to a flat monthly fee would be overpaying. Metered pricing exists for exactly that user, and it serves them well.

The third option: flat-rate

The case metered compute serves worst is the opposite one — sustained, read-heavy, getLogs-and-trace traffic, which is precisely what most indexers, explorers, and trading bots generate. When your steady-state workload is the expensive methods, every design decision becomes a billing decision: how often you poll, how wide you page, whether you can afford to trace. You end up optimizing your architecture around the meter instead of around your product.

Flat-rate RPC removes that pressure. You pay a fixed monthly price, and eth_getLogs costs the same as eth_blockNumber — which is to say, nothing extra. This is the model SwiftNodes runs: one key, one price, no compute-unit math, no surprise bill when a mint-day spike or a big backfill multiplies your heavy calls.

import { createPublicClient, http } from "viem";
import { mainnet } from "viem/chains";

const client = createPublicClient({
  chain: mainnet,
  transport: http("https://rpc.swiftnodes.io/rpc/eth?key=YOUR_API_KEY"),
});

// On a metered provider, a wide getLogs backfill is your most expensive line item.
// On flat-rate, it's just a request.
for (let from = 18_000_000n; from < 18_100_000n; from += 2_000n) {
  const logs = await client.getLogs({ fromBlock: from, toBlock: from + 1_999n });
  // ... index logs ...
}

Flat-rate is not automatically cheaper — if you're a low-usage hobbyist, a free metered tier will beat any paid plan. The win is predictability and the removal of per-method penalties once your usage is real and read-heavy. You size the plan once and stop thinking about the meter.

The decision in one line

If you need enhanced APIs and tooling, Alchemy. If you need redundancy, breadth, or no-commit pricing for light usage, dRPC. If your production workload is sustained and heavy on eth_getLogs and traces — and you'd rather buy a predictable number than audit a compute-unit invoice every month — that's where flat-rate earns its place.

The honest framing is that this is three answers to three different shapes of workload, not one provider beating the others. Map your real method mix and your real volume first; the right billing model falls out of that. If your map points at predictable, read-heavy traffic, grab a free key at swiftnodes.io, point it at our Ethereum RPC or any of the 50+ chains we run, and see what a flat line on the bill feels like.

Related posts

Try SwiftNodes free — multi-chain RPC across 75+ networks, flat-rate pricing, crypto-payable, no KYC. Get an API key in 30 seconds →