Alchemy Alternatives for Ethereum RPC in 2026

Alchemy is often the first serious upgrade a team makes after outgrowing a free endpoint, and it earns that position: the SDK is pleasant, the enhanced APIs remove real work, and the free tier is generous enough to carry a project a long way. The reasons people start shopping for an alternative are rarely about quality. Usually it is the compute-unit meter climbing faster than traffic, the slow realization that the enhanced APIs which saved time have also become hard to leave, or a latency-sensitive workload that would rather sit next to the node than call across the internet to reach it. This post is an honest look at the alternatives in 2026, what to weigh, and where each one actually fits. Provider plans, compute-unit weights, and enhanced-API pricing change often; treat this as a qualitative snapshot as of July 2026 and confirm against official docs before you migrate.

Why teams look past Alchemy

The first friction is usually the compute-unit model. Alchemy prices each method by a compute-unit weight, so your bill tracks the shape of your workload rather than a simple request count. A plain read and a debug_traceTransaction are both one call but can differ by two orders of magnitude in cost, which means a small slice of heavy methods often sets most of the invoice. Forecasting a monthly bill therefore means modeling your method mix, a job few teams have time for, so the real number tends to arrive with the invoice. Our compute units vs credits breakdown works a full example through both models.

The second is quieter and shows up later: lock-in through the enhanced APIs. The SDK, the Transfers and NFT APIs, and Notify webhooks are genuinely convenient, but they are Alchemy-specific rather than standard JSON-RPC. The more of your codebase leans on them, the less a migration is a one-line URL change and the more it becomes a rewrite. Convenience that only exists on one provider is a cost you pay at the exit, not the entrance.

The third is latency and locality. Even a fast, feature-rich gateway is still a gateway: every call leaves your machine, crosses the public internet, and comes back, typically in the tens to low hundreds of milliseconds depending on region, peering, and provider load. For a read-then-act loop in trading or MEV, that round trip often dominates everything else you optimize. We trace where that round-trip budget actually goes in why MEV is a latency game.

None of this makes Alchemy a poor choice. It makes it a feature-rich remote gateway optimized for the median developer, which is exactly right for many teams and slightly wrong for latency-sensitive or high-volume node workloads.

What to actually evaluate

Before comparing names, decide which of these you are actually optimizing for, because no single provider wins on all of them at once. Latency comes first if you run a bot or a searcher that reads state and acts on it inside a block, since remote RPC adds a round trip that colocation removes. Next is the pricing model and how it meets your traffic shape, because compute units, credits, and bundled allowances all bill the same workload differently. Then come limits: block range per eth_getLogs, result caps, requests per second, and which namespaces sit behind higher tiers, covered in the deep dive on eth_getLogs block range limits. Archive and mempool access matter if you need historical state at any block or a real-time view of pending transactions. And two easy-to-forget factors are portability, meaning how much of your code depends on proprietary APIs you cannot take with you, and where your code is allowed to run: pure RPC, or a full container next to the node.

The options

Infura is the other default gateway, reliable and widely documented, and a reasonable pick if you mainly want a second provider for redundancy or a simpler feature surface. It shares Alchemy’s shape, remote calls billed by usage, and we cover it in depth in the Infura alternatives guide.

QuickNode is fast, supports a long list of chains, and offers an add-on marketplace plus short edge functions for logic near the RPC. It bills in credits rather than compute units, which some teams find easier to reason about; the QuickNode alternatives guide goes deeper on where it fits.

Chainstack competes mainly on price and on dedicated nodes at higher tiers. If your driver is a cheaper per-request rate or dedicated capacity without operating hardware yourself, it is worth a quote.

Self-hosting Geth, Nethermind, Reth, or Erigon gives you maximum control, no request meter, and the lowest latency when your app sits on the same box. The cost is operational: sync times, disk, upgrades, and monitoring become your team’s job. Archive requirements in particular vary widely by client and pruning mode, so check current client docs before sizing hardware.

BLAZED.sh takes a different shape. Instead of handing you an endpoint to call over the internet, it runs your container or script on the same server as a fully synced node, and you talk to the chain over a local socket (ws://eth:8545 today; IPC is the maximum-performance local transport in general and a planned direction). Reads never cross the public network, pricing is per-request credits with a deliberately narrow weight spread drawn from a monthly allowance rather than a wide compute-unit table, and archive and mempool access come included rather than gated behind a premium tier. The trade-off is that it is built for backend workloads near the node, not for serving a browser wallet from a CDN edge.

The compute-unit question

The clearest way to see the difference is to look at how each model turns the same workload into a bill.

Under compute units, the honest forecast requires knowing the weight of every method you call and how often you call it, and the weights that matter most are the ones on the heavy methods you cannot easily avoid. Under a narrow-spread credit model, most methods cost the same single credit and a few heavy operations cost a small fixed multiple, so the estimate collapses to multiplying calls by a nearly uniform number and checking it against your monthly allowance.

Side by side

Limits and pricing move over time and vary by plan, so treat the table as a starting point and check official docs before you design around any single number.

Who should pick what

If your complaint is a specific feature gap or you simply want a second gateway for redundancy, Infura is the cleanest sibling swap and QuickNode adds performance plus a few serverless hooks. If your driver is purely per-request price with dedicated capacity, get a quote from Chainstack, and if price alone is driving the search, the cheapest Ethereum RPC breakdown prices each model against real traffic shapes. If you want full control and have the ops appetite to run clients yourself, self-host. And if the pain is compute-unit forecasting, enhanced-API lock-in, or the latency of high-volume node access, the gateway model itself is the limit, and the fix is to stop calling across the network: run your code on the node with BLAZED.sh and its predictable credit pricing.

Migrating off Alchemy

At the plain JSON-RPC level, ethers does not care who hosts the endpoint, so the core of a migration is a one-line URL change.

import { ethers } from 'ethers';

// Before: Alchemy
// const provider = new ethers.JsonRpcProvider('https://eth-mainnet.g.alchemy.com/v2/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);

The part that takes real work is anything built on the enhanced APIs, since the SDK, Transfers, NFT, and Notify calls have no drop-in equivalent on a plain endpoint and need to be rebuilt against standard methods or replaced. That rebuild is also the moment to decide where the replacement should live: a Notify-style webhook, for instance, is a small persistent service that watches the chain and posts events, and it runs best next to the node rather than polling it from afar. We walk through exactly that pattern in building real-time Ethereum event notifications. On BLAZED.sh the endpoint change is smaller in spirit than a provider swap: drop the remote URL and connect to the co-located node over its local WebSocket with new ethers.WebSocketProvider('ws://eth:8545'), and the service that was calling Alchemy from a separate host moves into a container on the node itself.

Conclusion

There is no single best Alchemy alternative, only the best fit for the constraint you are actually hitting. If it is a feature gap, a sibling gateway like Infura or QuickNode solves it without changing the model. If it is compute-unit math, the lock-in of proprietary APIs, or latency from high-volume node access, the gateway model itself is the limit, and the alternative worth trying is to move the code next to the node, where calls stay on a local socket, pricing is a narrow credit spread you can forecast by counting, and the enhanced features you were renting become a service you own.