Skip to content

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: Oct 7, 2026, 07:46 UTC

Alchemy0.00 ms
QuickNode0.00 ms
dRPC0.00 ms
Infura0.00 ms

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

Chains
Regions

Average Latency

0.00ms

Alchemy

P50 Latency

0.00ms

Alchemy

P95 Latency

0.00ms

Alchemy

Success Rate

0%

Alchemy

Provider comparison for all benchmarked chains in all regions

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

RPC provider benchmark table comparing average latency, P50 latency, P95 latency, and success rate for the selected chain and region.
ProviderAvg latencyP50 latencyP95 latencySuccess rate
AlchemyFastest
13.63 ms
6.11 ms
29.83 ms
100%
QuickNode
41.71 ms
9.58 ms
181.27 ms
99.99%
dRPC
111.78 ms
29.45 ms
585.69 ms
99.97%
Infura
427.17 ms
142.52 ms
1417.64 ms
0.83%

Average latency by method: all benchmarked chains, all regions

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

7.05 ms
13.19 ms
40.73 ms
442.65 ms
  • Alchemy
  • QuickNode
  • dRPC
  • Infura

Failed requests by method: all benchmarked chains, all regions

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

0
0
1
102818
  • Alchemy
  • QuickNode
  • dRPC
  • Infura

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.

Read the full methodology
Payload icon

Same payloads

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

Regions icon

Shared runner regions

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

Accounts icon

Standard paid accounts

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

Latency icon

Successful-response latency

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

Failure rules icon

Clear failure rules

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

Scope icon

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.

Open Markdown data

FAQs

Benchmark FAQs

How the live RPC benchmarks work, what they measure, and where to find the raw data.

  • 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.
  • 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.
  • The benchmark runs from US East, US West, EU Central, and AP Southeast. The Global view aggregates results across those four regions.
  • 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.
  • 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.
  • 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.
  • 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.
  • The live benchmarks cover Ethereum, Optimism, Arbitrum, Base, and World Chain, plus an Overall view that aggregates the currently benchmarked chains.

  • 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
  • Yes. The companion Markdown page publishes the results as text tables with field definitions, source metadata, and the full chain-by-region dataset.
  • 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.
  • 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.

Latency is a tax on your users

Every slow RPC call turns into user-facing drag: delayed reads, stuck screens, and confirmations that feel broken. Build on infrastructure that keeps your app moving.

Start buildingContact us