Getting a dedicated node

A public RPC endpoint is one URL in front of a pool of nodes shared by everyone who found it. That is not a criticism — it is the deal. You pay nothing, you register nothing, and in exchange you get whatever capacity is left after everyone else, on hardware sized for an average that you are not obliged to resemble.

Almost none of them promise anything. Of the providers measured here, one publishes an uptime SLA, and reading it carefully is instructive: it covers that company’s paid product, not the free gateway we measure. Two others publish the opposite of a promise.

That sentence is the most useful thing any of them publish, because it is the only one that tells you what the endpoint is for. Everything on the providers page that a company states about its own limits is quoted there with the date it was read, for the same reason: a limit you heard about in a forum post is a rumour, and a limit with no date attached cannot be checked for staleness by the person it is about to surprise.

Nobody moves off a public endpoint because of a blog post. They move because something specific broke, and it is almost always one of these five. Each is worth naming, because each has a different answer and only two of them are solved by paying.

You are being rate limited

HTTP 429, or a JSON-RPC error mentioning a quota. The fix is capacity: a paid tier, a dedicated node, or your own. Retrying harder is not a fix, and is the single most common way a struggling application turns a throttle into a ban.

The method exists but is not sold to you

“Available for paid plans only”, or a request to register. Distinct from the method not existing, and worth checking on the method matrix before you conclude a provider cannot do something it simply will not do for free.

The history is not there

A state read at an old block, or a wide eth_getLogs range, is refused or truncated. This is an archive question, not a capacity one, and paying the same provider more may not change it. Archive depth is measured here per endpoint, in rungs, because the exact boundary moves every block and an order of magnitude is what you actually need to know.

You are behind the chain

The endpoint answers quickly with state that is a few blocks old. This is the failure that looks like success in every latency benchmark, which is why a stale answer is counted as a failure here and why block propagation is measured as a race between providers rather than as an absolute time.

You need to be somewhere specific

A trading system in Frankfurt calling an endpoint that terminates in Virginia has bought 80ms it can never optimise away. Regional latency is measured from separate vantage points for exactly this reason — where a measurement was taken is part of the measurement.

The second and third are worth an example, because they are the two people most often mistake for an outage. BNB Chain disables one method outright on its public endpoints and says so plainly:

An application that discovers this at runtime sees errors from a working endpoint and concludes the chain is down. Reading the documentation first is free; so is checking what each endpoint answers, which is measured here precisely because reading sixteen sets of documentation is not.

The word is sold for at least four different things, and the difference between them is the difference between the problem you fixed and the one you are still going to have.

The questions that separate them are boring and worth asking in writing, because the answers are rarely on the pricing page:

• Is it single-tenant, and single-tenant on what? One node? One machine? One pool that happens to be small today?
• Full or archive, and which archive? “Archive” means every historical state to some vendors and every historical receipt to others. Ask for the block number they can serve eth_getBalance at.
• Which client, and can you know? It decides which non-standard methods exist, how deep the archive goes, and how a wide log query behaves. The clients articles — Ethereum, BNB Smart Chain, Solana — cover what changes with each.
• Where does it terminate? Not where the company is — where the node is, and whether there is one anywhere near your users.
• What happens during an upgrade? Every chain hard-forks. Who applies it, when, and what is the failure plan if it goes wrong at 2am on a Saturday.
• Is there an SLA, and does it cover this product? This one has a specific trap, below.

A managed node has a price on a page. Self-hosting has a price you assemble yourself, and comparisons usually assemble only the parts that make the answer come out the way the author already decided.

The whole list, for one node, per month:

• The machine. Rented monthly, or bought and divided by however long you think it lasts. Cheapest to get right, because it is the one number everybody remembers.
• The disk, sized for a year from now. Chain data grows monotonically and resizing a full node is a resync. Each chain’s published requirements are quoted in its own running-a-node article; treat them as floors, not targets.
• Egress. A node uploads continuously to its peers whether or not anybody is calling it. On metered cloud bandwidth this is routinely larger than the instance.
• A second one. One node is not a deployment, it is a single point of failure with a hostname. If you would not accept the provider having one, do not accept having one yourself.
• Your time, at your rate. Initial sync, upgrades on the chain’s schedule rather than yours, disk that fills at 4am, and the monitoring in the observability article that tells you before your users do.

Written out, the comparison usually resolves itself. Self-hosting wins decisively at high and sustained request volumes, where the managed price scales with usage and yours does not. Managed wins nearly everywhere else, and wins by more than it looks like it does, because the last item on that list is the one that gets estimated at zero and invoiced in weekends.

Roughly, and with the caveat that every application is the exception to something:

Stay on public endpoints

While you are building, and in production only if a failed request is an inconvenience rather than an incident. Use more than one, always, and read the status page before blaming your own code.

Buy a paid tier

When rate limits are your only problem. It is the cheapest fix, it takes an afternoon, and it buys you a support address — which is worth more than it sounds when you need to ask why a method behaves oddly.

Buy a dedicated node

When you need predictable capacity, a specific region, or an archive that a shared tier will not serve — and when you would rather not be the one holding the pager. Ask the six questions above before signing.

Run your own

When volume makes the managed bill absurd, when you need a client or a configuration nobody sells, or when the ability to keep working while a vendor has an outage is worth an engineer’s ongoing attention. Start with the running-a-node article for your chain: Ethereum, BNB Smart Chain or Solana.

Whatever you choose, choose two. Every measurement on this site is of a single provider at a single instant, and the pattern in the incident record is that providers fail independently — which is only useful to you if you are in a position to use the other one.