Which RPC Provider Has the Highest RPS? Rate Limits and Throughput Compared Across 11 RPC Providers (2026)

Among self-serve plans, Dwellir's Scale plan publishes the highest documented sustained figure at 5,000 responses per second with 10,000 burst for $999/month. dRPC markets 5,000 RPS on its paid tier, and its docs say paid traffic carries no rate limit at all. BlockPI publishes 2,500, Ankr around 1,500 per endpoint, Alchemy around 1,150 eth_call/s, thirdweb 1,000, GetBlock 800, Chainstack 600, and QuickNode, Helius and Infura Team 500. Those figures use different units, apply at different scopes, and none of them is a guarantee.

The 429 rarely arrives at the end of the month. It arrives on a Tuesday afternoon with most of your monthly quota still unspent, because a quota and a rate are two different budgets and only one of them is measured in seconds. A plan that includes 150 million requests a month and caps you at 50 per second will reject traffic the moment your users, your indexer and your cron job line up.

Pricing pages put RPS in the headline and then define it four different ways. One provider counts responses, one counts compute units, one counts credits, one counts requests and request units at the same time. A "300 RPS" label can mean 385 eth_call per second or 167 eth_getLogs per second depending on which method your code sends. This post normalises all of it into one table, then explains why the number on the pricing page is not the number you get.

RPC Provider Rate Limits Compared (2026)

Every figure below was checked against the provider's own pricing page or rate-limit documentation on 19 September 2026. Where a provider meters in compute units or credits, the RPS shown is the eth_call-equivalent: units per second divided by that provider's published unit cost for eth_call. Lighter methods get more, heavier methods get considerably fewer.

All figures are eth_call-equivalent where the provider meters in units, checked against provider pricing and documentation pages on 19 September 2026.

Price and throughput are barely correlated across this set. A $225 Infura Team plan and a $999 QuickNode Business plan both land on 500 eth_call per second. The entry tiers cluster tightly on price and spread 20x on rate, with seven providers charging $49 or $50 for somewhere between 50 and 1,000 RPS. Free tiers span a 17x range, from Infura's 6 eth_call/s to dRPC's roughly 100 per IP. Only two providers publish a burst figure at all, and only Dwellir publishes an explicit bucket capacity.

Two caveats the table cannot fit. BlockPI's packages expire after 60 days (Elementary) or 90 days (Premium), so the effective monthly cost of its 2,500 RPS tier is higher than the $299 sticker. Ankr's Premium figure is a load-dependent approximation in its own docs, not a fixed cap.

Four of these providers also sell a flat-rate RPS product, where the request meter is off and you buy a rate instead of a volume. Those are priced per RPS per month rather than per million calls, and the rungs do not line up cleanly across vendors. The full price-per-RPS breakdown sits in what an unlimited RPC node is and how flat-rate providers compare.

Why "RPS" Means Four Different Things

The unit is the first thing to check, because it changes the answer by an order of magnitude.

Responses per second. Dwellir counts one response as one unit regardless of method. A debug_traceTransaction costs the same as an eth_blockNumber, a batch of 50 calls counts as 50, and WebSocket messages count in both directions. The RPS figure means the same thing for every method you send.

Compute units per second. Alchemy meters CU/s at account level. eth_call is 26 CU, eth_getBalance 20, eth_blockNumber 10, eth_getLogs 60. The Pay As You Go tier includes 10,000 CU/s, which Alchemy labels "300 RPS" on its pricing page. Run eth_call and you get about 385 per second. Run eth_getLogs and the same budget yields about 167 per second. Alchemy's own RPS labels imply a blended mix at roughly 20 to 33 CU per request, not a specific method.

Alchemy's free tier is worth flagging because the vendor contradicts itself. Two documentation pages say 300 CU/s; the pricing page says 500 CU/s and labels it "25 requests per second". The docs figure is the one used in the table above.

Credits per second. Infura publishes no RPS figure anywhere, so every conversion here is ours. eth_call, eth_getBalance, eth_blockNumber and eth_sendRawTransaction are 80 credits each; eth_getLogs is 255; debug_trace* methods are 1,000. The $50 Developer plan's 4,000 credits/s therefore buys 50 eth_call per second, about 16 eth_getLogs per second, or 4 debug traces per second. Same plan, same second, three different ceilings.

RPS and request units at the same time. BlockPI enforces both, so a Premium package is 2,500 RPS and 100,000 RU/s, and heavy methods hit the RU ceiling long before the request ceiling. Chainstack and GetBlock pair a plain RPS cap with a monthly unit quota, which is the same idea on a longer timescale.

Plain requests per second. QuickNode, GetBlock and thirdweb publish one number per plan with no method weighting on the rate limit itself. Chainstack and Helius publish one headline number too, with per-method overrides layered underneath it, covered below. That is the easiest unit to reason about, which is why it is worth checking whether a monthly quota sits underneath it.

The practical rule: before comparing two providers, divide each headline number by the unit cost of the method that dominates your traffic. If your workload is 80% eth_getLogs, a CU-metered plan is worth between a third and a half of the rate its eth_call maths implies. For the wider set of providers that have dropped unit metering entirely, see RPC providers without compute units, and for cost per million calls on Ethereum, Best Ethereum RPC Providers.

Per Account, Per Key, Per Endpoint, or Per IP

The second thing that breaks comparisons is scope. The same 500 RPS means something different depending on what it is attached to.

• Per account. Dwellir, Alchemy and Infura pool the limit across everything on the account. Dwellir's rate limits documentation says it directly: creating additional keys divides your existing budget rather than adding to it. Spinning up a second key to dodge a 429 does not work on any of the three.
• Per endpoint. QuickNode's Flat Rate RPS, Ankr's Premium tier and GetBlock's Limitless Node attach the rate to a single endpoint. Buying a second endpoint genuinely does add capacity, and it also adds a second invoice line.
• Per IP. dRPC's free tier enforces 120,000 CU per minute per IP address. This is the one that surprises teams, because in Kubernetes every pod behind a NAT gateway shares one budget. Ten replicas do not get ten allowances, and the limit tightens under regional load to 50,400 CU per minute, which dRPC puts at about 40 eth_call per second.
• Per node or per plan. GetBlock's Limitless Node runs on an isolated instance and the rate belongs to that node. Helius publishes RPS per plan with separate per-method sub-limits layered on top.

Scope determines your architecture. On per-account limits you need a client-side scheduler sharing one budget across services. On per-endpoint limits you can isolate the indexer from the user-facing API by buying two endpoints, which is usually cheaper than buying one much larger plan.

Sustained vs Burst: The Token Bucket in Numbers

Most gateways run a token bucket. A bucket holds up to some capacity of tokens and refills at a fixed rate; each request spends a token; an empty bucket returns 429. The refill rate is your sustained throughput. The capacity is your burst.

Dwellir publishes both numbers, which makes the mechanism concrete. On the $299 Growth plan the refill rate is 500 responses per second and the bucket capacity is 2,500. Sit idle for five seconds and you can fire 2,500 requests in one go, then the bucket drains and you are back to 500 per second while it refills. On the $999 Scale plan the pair is 5,000 and 10,000. On the $49 Developer plan it is 100 and 500.

Alchemy publishes the rate and the window rather than the capacity: CU/s is evaluated over a 10-second rolling window with strict refill, so a 300 CU/s account can spend 3,000 CU inside any 10 seconds. That is a 10x burst allowance expressed differently. Alchemy also notes the cap is elastic upward, and that the system may allow higher throughput based on available capacity.

QuickNode documents no bucket at all. The Flat Rate RPS docs are blunt: if 100 requests arrive in one second on a 75 RPS tier, 75 are processed and 25 return HTTP 429. Nobody else in the table publishes a burst figure, so assume strict per-second enforcement unless you have load-tested otherwise.

This is why a workload with a healthy-looking average still fails. Average RPS is measured over minutes; the bucket is measured over seconds. On a 20 RPS free tier, 100 requests fired in one second get 80 rejections, while the same 100 requests spread over 5 seconds all succeed. The shape of the traffic decides the outcome.

The Second Throttle Under the RPS Cap

Clearing the RPS cap does not mean the request goes through. Three other limits sit underneath it.

Concurrency. QuickNode's Flat Rate RPS tiers ship 2, 4 and 6 concurrent connections on the 75, 150 and 250 RPS tiers, and both limits apply simultaneously. QuickNode publishes the arithmetic: effective throughput equals concurrent connections divided by response time. With 2 connections and a 100 ms eth_call, the ceiling is 20 RPS on a tier sold as 75. Reaching 75 needs mean response times at or under about 27 ms. Trace calls, which QuickNode notes can run for seconds, collapse the same tier to well under 1 RPS.

Per-method caps. Helius sets separate ceilings for sendTransaction and getProgramAccounts that are far below the plan RPS. Chainstack overrides by chain and method: Solana getProgramAccounts runs at 3 to 10 RPS depending on region, Arbitrum debug_traceBlockByNumber at 20 RPS on all plans, Fantom debug_traceBlock* at 5. Your plan number is irrelevant if your hot method has its own cap.

Block-range and response-size limits. These reject requests nowhere near any rate limit. Dwellir allows 500-block eth_getLogs ranges on Developer and 10,000 by default on Growth and Scale; Chainstack allows 100 on free and 10,000 on paid. Alchemy returns "Log response size exceeded. You can make eth_getLogs requests with up to a 2K block range and no limit on the response size, or you can request any block range with a cap of 10K logs", and Infura returns "query returned more than 10000 results".

Both strings show up verbatim in ethers.js issue #4703, and issue #5061 shows contract.on() breaking with "Block range limit exceeded" because eth_newFilter omitted fromBlock. An indexer experiences these as a throughput limit even though the rate limiter never fired. The pagination patterns are in the eth_getLogs limits guide.

How Much RPS Does Your Workload Actually Need

Size for the moment when every source peaks together. NoLimitNodes' sizing guide publishes burst coefficients that hold up as a starting point, and the public endpoints give you the floor.

The trading-bot row is the one people get wrong. NoLimitNodes walks through a liquidation bot that looks like 10 weighted RPS in steady state and needs roughly 400 RPS once you add confirmation polling (up to 60 getSignatureStatuses calls per send), an 8x burst and a 2x retry buffer. They also record a bot averaging 8 RPS that hit 140 RPS for 90 seconds during a token launch. Chainstack's rule of thumb is consistent: shared endpoints work for bots running below roughly 50 RPS with predictable traffic, and above that the rate limit becomes the binding constraint during volatility.

Public endpoints set the floor. Solana's public cluster allows 100 requests per 10 seconds per IP, and the docs point production infrastructure at the RPC provider guide instead. Hyperliquid caps its REST API at 1,200 aggregated weight per minute per IP and its public EVM RPC at 100 JSON-RPC requests per minute, covered in Top Hyperliquid RPC Providers. Base's public endpoint carries the label "rate limited and not for production systems" in its own docs.

What a 429 Means and How to Handle It

A 429 from an RPC endpoint means the gateway refused the request because you sent too many in a given window. RFC 6585 defines the status code, and the response may include a Retry-After header. The request was never executed and the node never saw it. Three causes account for almost all of them: a burst above your per-second cap, heavy methods spending more units than you budgeted, and an exhausted daily or monthly quota.

The bodies differ enough to matter. Dwellir returns HTTP 429 with a JSON-RPC error inside it:

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32005,
    "message": "Rate limit exceeded"
  }
}

Infura returns HTTP 429 with a JSON-RPC error code of 429 and event -33200. The body tells you which limit you hit, but carries no backoff figure:

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": 429,
    "event": -33200,
    "message": "Too Many Requests",
    "details": "You have surpassed your allowed throughput limit. Reduce the amount of requests per second or upgrade for more capacity."
  }
}

Two traps live in those payloads. Infura's 429 body used to carry current_rps, allowed_rps and backoff_seconds; the current one gives you a details string and nothing to schedule a retry from. Alchemy can return code 429 inside an HTTP 200 when the call was part of a JSON-RPC batch, and its Retry-After header is optional rather than guaranteed, both documented in Hardhat issue #3501. Parse the body, not just the status code.

Infura also has a separate failure mode worth designing around: when the daily credit quota runs out you get HTTP 402 with event -33000, and the service halts until 00:00 UTC, severing WebSocket connections. Backoff will not help you there.

A retry handler that covers both cases:

const MAX_BACKOFF_MS = 32_000;

function parseRetryAfterMs(header: string | null): number {
  if (!header) return 0;
  const seconds = Number(header);
  if (Number.isFinite(seconds)) return seconds * 1000;
  const at = Date.parse(header); // HTTP-date form, RFC 9110
  return Number.isNaN(at) ? 0 : Math.max(0, at - Date.now());
}

async function rpcCall(url: string, body: unknown, attempt = 0): Promise<any> {
  const res = await fetch(url, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(body),
  });

  // 402 means the daily quota is gone. Retrying will not fix it.
  if (res.status === 402) throw new Error("Quota exhausted, failover to a second provider");

  const json = res.status === 429 ? null : await res.json();

  // Alchemy can return code 429 inside an HTTP 200 batch response.
  const rateLimited =
    res.status === 429 ||
    (Array.isArray(json) && json.some((r) => r?.error?.code === 429));

  if (rateLimited) {
    if (attempt >= 5) throw new Error("Rate limited after 5 attempts");

    // Honour Retry-After when the provider sends it (delay-seconds or an HTTP date),
    // otherwise back off exponentially.
    const retryAfter = parseRetryAfterMs(res.headers.get("retry-after"));
    const backoff = Math.min(2 ** attempt * 250, MAX_BACKOFF_MS);
    const jitter = Math.random() * 250; // spreads retries across concurrent callers

    await new Promise((r) => setTimeout(r, (retryAfter || backoff) + jitter));
    return rpcCall(url, body, attempt + 1);
  }

  return json;
}

The jitter matters. QuickNode's rate-limiting explainer describes the failure mode without it: retries that are not staggered create a feedback loop where rate-limited requests generate more requests, and your client hammers the wall in lockstep.

Four steps raise your effective rate, in the order to try them:

1. Batch and cache. Immutable data (receipts, historical blocks, finalised balances) should never be fetched twice. Infura's guidance is to limit calls at startup and cache anything older than a couple of blocks.
2. Spread the burst. Move from tight polling to eth_subscribe, and put a client-side token bucket in front of your own traffic so you shape it instead of letting the gateway reject it.
3. Honour Retry-After and back off with jitter. Fast failure is manageable. A retry storm is not.
4. Move the cap. Upgrade the plan, buy a flat-rate RPS tier, or move to dedicated capacity. Do this last, because a badly shaped client gets throttled at a higher price.

Rate Cap or Guarantee: Shared, Flat, or Dedicated

There are three rungs. Only the third promises throughput.

Shared metered plans. The RPS number is the most the gateway will admit. Below it you get whatever the pool can serve, and the pool has other tenants. Dwellir's Unlimited Node docs put it in those terms: "It is not a throughput guarantee. Beneath the cap you get whatever the cluster behind the endpoint can serve."

Flat-rate RPS tiers. The meter is off and you buy a rate, but the infrastructure underneath is usually still shared. QuickNode says so explicitly: Flat Rate RPS runs on "Shared Pro infrastructure without SLA guarantees or infrastructure isolation". GetBlock is the exception in wording, calling its Limitless Node RPS "guaranteed" because each node runs on an isolated dedicated instance, though no measurement is published to back it. Chainstack's Chainbench post is the fairest summary of the category: "'No rate limits' means little when a single balance query takes 15 seconds during network congestion."

Dedicated clusters. Hardware is allocated to you, throughput is whatever the hardware does, and the SLA is contractual. Chainstack publishes a formula that works out to roughly $1,279/month for an Ethereum full node, Helius starts at $2,900/month, and GetBlock's dedicated nodes start at $1,000/month with 1,000+ guaranteed RPS. Dwellir's pricing page lists archive clusters from $2,400/month (Base at $3,366), with full-node clusters quoted separately, and dedicated node clusters carry no rate limit, no request counting and a custom SLA of up to 99.99%.

Move up a rung when your sustained requirement passes roughly 1,000 RPS, where dedicated capacity costs less per unit of throughput than stacking shared tiers, or when your product depends on tail latency rather than average latency. Running the node yourself removes the rate limit and replaces it with a hardware ceiling and an on-call rota, a trade worked through in self-hosted vs managed RPC nodes.

Choosing a Provider by Throughput Need

Three brackets cover almost every team. For the wider feature and price comparison behind these picks, see the best RPC node providers.

Bursty traffic that averages under 500 RPS: a shared metered plan. Several providers fit and the prices are close. GetBlock sells 800 RPS for $499 and thirdweb 1,000 RPS for $499, against Dwellir's 500 RPS for $299 on the Growth plan. Dwellir costs less per request on method-heavy workloads, because trace and debug count as one response each, and it is the only plan in the bracket that tells you what its burst capacity is. If your traffic is smooth and your method mix is light, GetBlock and thirdweb are the better raw number.

Constant traffic at a known rate: buy a rate, not a volume. Flat-rate products win here, because a constant-rate workload run flat out on a metered plan costs more than the equivalent RPS tier. Chainstack's Unlimited Node is the right pick if you need one RPS pool across many chains, though it is an add-on that requires at least the $49 Growth plan, so the entry price is $198 rather than $149. GetBlock's Limitless Node is the cheapest way to buy 50 RPS ($300) or 250 RPS (its 300 RPS tier at $1,000). Dwellir's Unlimited Nodes are cheapest at 25 RPS ($119) and 100 RPS ($479), and the only self-serve product that reaches 1,000 RPS ($4,799) without a sales call.

Above 1,000 RPS or latency-sensitive: dedicated. Self-serve mostly stops here, for physical rather than commercial reasons: selling one account 5,000 RPS reserves a meaningful slice of a region's node pool. QuickNode's Flat Rate tops out at 250 RPS before sales, GetBlock's Limitless at 300, Chainstack's Unlimited Node at 500. Dwellir's Scale plan at 5,000 RPS is the exception on shared capacity. Chainstack, GetBlock, Helius and Dwellir publish list prices for dedicated hardware; Alchemy, QuickNode and Infura do not.

The number on the pricing page is a permission to send traffic, not a promise to serve it. Before you upgrade, work out three things about your own workload: which method dominates it, what its peak-to-average ratio looks like over a week, and whether the limit you keep hitting is the rate, a daily quota, a concurrency cap or a block-range cap. Those four failures look identical in a log line and have four different fixes. Pagination and caching fix two of them for free.

Dwellir's pricing page lists the sustained and burst figures for every plan, Unlimited Nodes covers the flat-rate rungs from 25 to 1,000 RPS, and the Dwellir team can scope a dedicated cluster if your peak sits above that. To measure your own ceiling first, the free tier runs at 20 RPS: get started.

Frequently Asked Questions

Which RPC provider has the highest RPS?

On published self-serve plans, Dwellir's Scale plan is the highest documented sustained figure at 5,000 responses per second with 10,000 burst for $999/month. dRPC markets 5,000 RPS on its paid tier and its docs say paid traffic is not rate limited at all. BlockPI Premium publishes 2,500 RPS, and Ankr Premium is around 1,500 requests per second per endpoint.

What does a 429 error from an RPC provider mean?

HTTP 429 means the gateway rejected the request because you sent too many in a given window, as defined in RFC 6585. It is not a node failure and the request was never executed. The three usual causes are a burst above your per-second cap, heavy methods consuming more units than you expected, and an exhausted daily or monthly quota.

Is the RPS on the pricing page guaranteed?

No. On shared plans it is a ceiling the gateway enforces, not a floor the backend promises. Dwellir states it plainly: an upper limit, not a guarantee. QuickNode says Flat Rate RPS runs on shared Pro infrastructure without SLA guarantees or infrastructure isolation. Contractual throughput means a dedicated node cluster.

How do compute units per second convert to requests per second?

Divide the units per second by the unit cost of the method you call. Alchemy charges 26 CU for eth_call, so 10,000 CU/s is about 385 eth_call per second. Infura charges 80 credits for eth_call and 255 for eth_getLogs, so 4,000 credits/s is 50 eth_call/s or roughly 16 eth_getLogs/s.

Are rate limits per API key or per account?

It varies, and the difference matters. Dwellir, Alchemy and Infura apply the limit at account level, so extra keys divide the existing budget rather than adding to it. QuickNode Flat Rate RPS, Ankr Premium and GetBlock Limitless Node apply it per endpoint. dRPC's free tier applies it per IP address.

How much RPS does a trading bot need?

More than its steady state suggests. Chainstack puts the shared-endpoint ceiling for bots at roughly 50 RPS. NoLimitNodes applies a 10x to 20x burst coefficient to bots and walks through a liquidation bot that needs around 400 RPS once confirmation polling, burst and a retry buffer are added to a 10 RPS average.

Sources

All provider figures checked on 19 September 2026.

• Dwellir rate limits and Dwellir pricing - plan RPS and burst, token bucket, per-account scope, -32005 body, eth_getLogs ranges
• Alchemy throughput, pricing plans, compute unit costs and pricing
• Infura pricing, Infura docs pricing, credit costs and avoiding rate limiting
• QuickNode pricing, Flat Rate RPS docs, 429 errors explained and what is RPC rate limiting
• Chainstack pricing, RPS plan limits, per-method limits and Unlimited Node
• Chainstack Chainbench - "'No rate limits' means little" quote
• dRPC pricing and rate limiting docs
• Ankr service plans
• GetBlock CU and rate limits and Limitless Node
• thirdweb pricing
• BlockPI pricing and rate limits
• Helius rate limits and pricing
• Solana public cluster limits and Hyperliquid rate limits
• RFC 6585 - HTTP 429 Too Many Requests
• Base docs, connecting to Base - public endpoint labelled "rate limited and not for production systems"
• Chainstack dedicated node pricing - published dedicated-node price formula
• Hardhat issue #3501, ethers.js issue #4703 and ethers.js issue #5061 - 429 inside batch responses, missing Retry-After, block-range and log-size errors
• NoLimitNodes RPS sizing guide and Chainstack's trading bot guide