Compare RPC performance across popular chains

See how providers compare on latency, success rate, and failed requests, all tested under identical conditions.

Global Average Response Time (EVM)

Live

Last updated: Sep 7, 2026, 04:50 UTC

In the current global 24-hour benchmark across EVM chains, Alchemy has the lowest average response time at 16.27 ms.

Chains

Provider comparison for all benchmarked chains in all regions

In this 24-hour view, Alchemy has the lowest average latency at 16.27 ms. The table also shows P50, P95, and success rate for each provider.

Average RPC latency over time: all benchmarked chains, all regions

How quickly each provider answers your app's requests over the last 24 hours. Lower, flatter lines mean faster and more consistent load times.

• Alchemy: 14.10 ms
• QuickNode: 45.25 ms
• Infura: 117.63 ms
• dRPC: 109.12 ms

RPC success rate over time: all benchmarked chains, all regions

How often each provider responds successfully instead of failing. The closer to 100%, the fewer errors your users run into.

• Alchemy: 100%
• QuickNode: 100%
• Infura: 99.70%
• dRPC: 99.98%

P95 RPC latency over time: all benchmarked chains, all regions

The slow end of the experience: how the slowest 5% of requests perform. Keeping this low means even your unluckiest users stay fast.

• Alchemy: 31.82 ms
• QuickNode: 226.78 ms
• Infura: 274.39 ms
• dRPC: 601.68 ms

Failed requests over time: all benchmarked chains, all regions

How many requests each provider dropped, errored, or timed out. Shorter bars mean fewer broken moments inside your app.

• Alchemy
• QuickNode
• Infura
• dRPC

Average latency by method: all benchmarked chains, all regions

Pick a method to see how quickly each provider handles that request type.

• eth_getBalance:
  • Alchemy: 8.59 ms
  • QuickNode: 13.16 ms
  • dRPC: 19.91 ms
  • Infura: 111.63 ms

Failed requests by method: all benchmarked chains, all regions

Pick a method to see where errors and timeouts cluster by provider.

• eth_getBalance:
  • Alchemy: 0
  • QuickNode: 1
  • dRPC: 15
  • Infura: 624

Methodology

Controlled RPC tests, transparent rules

These are method-level EVM read benchmarks. We send the same configured payloads from the same regions, separate speed from reliability, and publish the rules so the numbers are easier to interpret.

Same payloads

For each method, every provider receives the same configured JSON-RPC payload, chain, region, timeout, and success criteria.

Shared runner regions

Tests run from US East, US West, EU Central, and AP Southeast, with every provider tested from the same runner location.

Standard paid accounts

Every provider is tested on a standard paid RPC service account, with no special routes, plans, retries, or treatment.

Successful-response latency

Latency uses warmed, reused HTTP connections and only includes successful responses. Failures are tracked separately.

Clear failure rules

HTTP errors, JSON-RPC errors, parse failures, network errors, rate limits, and 8-second timeouts all count as failures.

Method-level scope

The benchmark measures individual read requests, not full app flows, writes, WebSockets, cold starts, or custom traffic mixes.

Benchmarks for agents

Open every benchmark view as text tables with field definitions and source metadata, built for agents, crawlers, and developers who want the data without the interface.

FAQs

Benchmark FAQs

• What metrics do Alchemy's RPC provider benchmarks track?
  They track successful-response latency (average, P50, and P95), success rate, and failed-request counts for Alchemy, QuickNode, dRPC, and Infura across common EVM JSON-RPC read methods.

• How often are the RPC provider benchmarks updated?
  Benchmark requests run every 10 seconds around the clock. The public page and Markdown data route refresh every 5 minutes with the latest 24-hour window.

• Which regions are included in the benchmark tests?
  The benchmark runs from US East, US West, EU Central, and AP Southeast. The Global view aggregates results across those four regions.

• Are these benchmarks comparing free or paid RPC tiers?
  They compare standard paid RPC service accounts. Every provider receives the same configured method, payload, chain, region, timeout, and success criteria with no special treatment.

• What counts as a failed RPC request in these benchmarks?
  A request fails if it returns a non-2xx HTTP status, returns a JSON-RPC error object, times out after 8 seconds, fails at the network level, or fails to parse as valid JSON. Rate-limit responses count as failures.

• How is RPC latency measured?
  Latency is the runner's measured request-and-response time for a successful JSON-RPC HTTP POST over a warmed, reused connection. Failed attempts and timeouts are excluded from latency and counted in success rate instead.

• Do the benchmarks use retries?
  No. Each attempted request gets one chance. If it fails, the failure is counted rather than retried away, so success rate reflects the failures an app would need to handle.

• Which chains are benchmarked?
  The live benchmarks cover Ethereum, Optimism, Arbitrum, Base, and World Chain, plus an Overall view that aggregates the currently benchmarked chains.

• Which RPC methods are tested?
  The benchmark covers configured EVM read tests for:

  • eth_getBalance: account balance lookup
  • eth_getBlockByNumber: earliest block, a header read at the start of the chain
  • eth_getBlockByNumber: latest block, a header read at the chain head
  • eth_getLogs: 1-block range
  • eth_getLogs: 10-block range
  • eth_getLogs: 100-block range
  • eth_getLogs: 1,000-block range on Ethereum
  • eth_getTransactionReceipt: single transaction receipt lookup.

• Can I access the raw RPC benchmark data?
  Yes. The companion Markdown page publishes the results as text tables with field definitions, source metadata, and the full chain-by-region dataset.

• How should I read P95 RPC latency?
  P95 shows the slow end of successful responses: 95% of successful requests in that method, chain, region, and time window completed at or below that latency. Read it beside success rate, because fast responses only matter when responses come back.

• What do these benchmarks not measure?
  They measure warm, single-method EVM read performance under controlled conditions. They do not measure full app workflows, write transactions, WebSockets, customer-specific traffic mixes, cold connection setup, or every possible chain, provider, region, method, and payload.