Infura is where most teams start, and for good reason: it is reliable, well documented, and free to begin with. The trouble usually shows up later, at scale, when the same properties that made it easy start to constrain you. If you are reading this, you have probably already hit a 429 Too Many Requests, watched a compute-unit bill climb, or realized your whole app depends on a single provider. This post is an honest look at the alternatives in 2026, what to weigh when choosing one, and where each option actually fits. Provider plans, quotas, and pricing change frequently; treat this as a qualitative snapshot as of July 2026 and check official docs before buying or migrating.
Why teams leave Infura
- Rate limits and 429s. Free and lower tiers throttle aggressively. A burst of traffic or an aggressive backfill turns into dropped requests right when you need them most.
- Compute-unit math. Pricing is per request weighted by method, so a single
eth_callcan cost very differently from adebug_traceTransaction. Forecasting a monthly bill means modeling your method mix, which few teams have time to do. - Single point of failure. If your dApp only knows one endpoint, an Infura incident is your incident. Provider redundancy is a real operational concern.
- Archive and trace gating. Historical state and
trace_/debug_namespaces sit behind higher tiers, so the queries that power analytics and MEV are the expensive ones.
None of this makes Infura bad. It makes it a general-purpose gateway, and general-purpose gateways optimize for the median user, not for your latency-sensitive or high-volume workload.
What to actually evaluate
Before comparing names, decide which of these you care about, because no single provider wins on all of them:
- Latency. Remote RPC adds a network round-trip; the exact number depends on region, peering, TLS, provider load, and your runtime. For trading, MEV, or any read-then-act loop, this often dominates everything else. We break down where those milliseconds actually go in why MEV is a latency game.
- Limits. Block range per
eth_getLogs, result caps, requests per second, and namespace access. These are plan- and provider-specific, and they change; see our deep dive on eth_getLogs block range limits. - Pricing model. Compute units, credits, request quotas, or flat-rate capacity. Predictability matters as much as the headline number.
- Archive and mempool access. Do you need historical state at any block, or a real-time view of pending transactions?
- Where your code runs. Pure RPC, edge functions, or full containers next to the node.
The options
Alchemy. The closest like-for-like swap. Strong tooling, enhanced APIs, generous free tier. Still a remote, compute-unit-priced gateway, so the latency and billing-predictability concerns carry over. A good move if your complaint is reliability or developer experience, not the gateway model itself. We compare its options in depth in the Alchemy alternatives guide, including where compute-unit pricing and enhanced-API lock-in start to pinch.
QuickNode. Fast, broad chain support, add-on marketplace, and edge functions for small bits of logic near the RPC. Credit-based pricing. A solid choice if you want performance plus a few serverless hooks, and you are comfortable with usage-based costs. The QuickNode alternatives guide goes deeper on its credit model and where it stops fitting.
Chainstack. Competitive pricing, dedicated nodes on higher tiers, and clear documentation. Worth a look if you want dedicated capacity without running hardware yourself, and you are price sensitive.
Self-hosting (Geth, Nethermind, Reth, Erigon). Maximum control, no provider request meter, and the lowest latency if your app sits on the same box. The cost is operational: sync times, disk, upgrades, and monitoring become your job. Archive storage requirements vary dramatically by client, configuration, pruning mode, and date, so check current client documentation before sizing hardware. Right for teams with the appetite to run infrastructure.
BLAZED.sh. A different shape entirely: instead of giving you an endpoint to call over the internet, it runs your container or script on the same server as a fully synced node. Today, the product endpoint is a local WebSocket on the host (ws://eth:8545); IPC remains the maximum-performance local transport generally and is a future BLAZED.sh direction. You get co-location latency without operating the node, predictable credit pricing with a simple weight spread instead of wide compute-unit accounting, a documented 1,000-block eth_getLogs window today, and mempool/archive-oriented access for code that wants to live next to the chain. The trade-off is that it is built for backend workloads near the node, not for serving a browser wallet from a CDN edge.
Side by side
| Infura | Alchemy | QuickNode | Self-host | BLAZED.sh | |
|---|---|---|---|---|---|
| Typical latency | remote network path | remote network path | remote network path | local if app is co-hosted | local WebSocket today; IPC planned |
| Pricing model | usage/plan based | usage/plan based | usage/plan based | hardware + ops | monthly credits |
| Rate limits / quotas | plan-based | plan-based | plan-based | your node/client capacity | platform/client safety limits, not plan-tier rate caps |
| Run your code on the node | no | no | edge functions | yes | yes (containers + scripts) |
| Archive access | higher tier | higher tier | higher tier | yes | included |
| You operate the node | no | no | no | yes | no |
Who should pick what
- Reliability or DX is the pain: Alchemy or QuickNode. A clean swap, same model.
- Price sensitivity with dedicated capacity: Chainstack. And if price is the whole question, start with the cheapest Ethereum RPC breakdown.
- You want full control and have an ops team: self-host.
- Latency-critical bots, MEV, indexers, or you are tired of compute-unit math: run on the node with BLAZED.sh, which uses predictable credit pricing instead of compute units.
Migrating off Infura
The good news: at the code level, ethers does not care who hosts the endpoint. Most migrations are a one-line URL change.
import { ethers } from 'ethers';
// Before: Infura
// const provider = new ethers.JsonRpcProvider('https://mainnet.infura.io/v3/YOUR_KEY');
// After: any standard JSON-RPC endpoint, read from the environment.
const provider = new ethers.JsonRpcProvider(process.env.RPC_URL);
async function main() {
const block = await provider.getBlockNumber();
console.log(`Connected, head block ${block}`);
}
main().catch(console.error);
On BLAZED.sh the change is even smaller in spirit: drop the remote URL and connect to the local WebSocket with new ethers.WebSocketProvider('ws://eth:8545'). For a complete example of a service built this way, see building real-time Ethereum event notifications.
Conclusion
There is no single best Infura alternative, only the best fit for the constraint you are actually hitting. If it is reliability, a sibling gateway like Alchemy or QuickNode may solve it. If it is latency, cost predictability, or quota pressure from high-volume node access, the gateway model itself may be the problem, and the fix is to stop calling across the network: run your code on the node.