Public RPC vs Paid RPC: Latency, Reliability, and Limits

Every chain has a free public RPC endpoint. They're listed on Chainlist, they need no signup, and they work the instant you paste them into your code. For learning a new chain, writing a one-off script, or prototyping over a weekend, they're genuinely great — don't pay for what you can get free.

The problem is the quiet assumption that "it worked in my test, so it'll work in production." Public RPC and production RPC are different jobs, and the gap between them is where outages live. Here's where free endpoints break down, and where paying actually buys you something.

Where public RPC bites you

Rate limits — aggressive, shared, and undocumented. A public endpoint is shared by everyone who pasted that URL. Its rate limit isn't yours; it's the whole internet's, and you don't know what it is until you hit it. Under any real load you start eating 429 Too Many Requests, often without warning. (We wrote a whole post on surviving Solana's 429s because of exactly this.)

Reliability — no SLA, and chains get dropped. Public endpoints go down with no status page and no recourse. Worse, providers deprecate chains: we recently watched every free public endpoint for two niche chains go dead within weeks — "unsupported platform," "unknown network," gone. If your product depends on a free endpoint, you inherit the operator's priorities, and a low-traffic chain is the first thing they drop.

Latency — variable and often slow. Shared infrastructure behind a load balancer means inconsistent response times, and heavy calls suffer worst. We've measured a public eth_getLogs taking 9–20 seconds where a dedicated node returns in well under one. Your p50 might look fine; your p99 is a timeout.

Stale blocks — the subtle one. Public endpoints sit behind load balancers spreading requests across many nodes, and not all of them are at the chain tip. You can send two requests a second apart and get answers from nodes at different heights — or query a transaction that "doesn't exist yet" because you hit a node that's a few blocks behind. Hard to reproduce, brutal to debug.

Missing methods. Many public endpoints disable debug_*/trace_*, cap eth_getLogs block ranges hard, and don't serve archive state. The moment you need a historical eth_call or a trace, the free endpoint returns an error and you're stuck.

No support. When something breaks at 2 a.m., there's no one to ask and nothing to escalate. You debug a black box you don't control.

The comparison

So when is each right?

Public RPC is the correct choice for: learning a chain, prototyping, one-off scripts and backfills you can babysit, hobby projects with trivial volume, and — importantly — as a fallback endpoint behind your primary.

Paid RPC earns its keep when: you're in production, you have users who notice downtime, your volume is enough to trip shared rate limits, you need archive/debug/trace, or you're on a chain that public providers treat as an afterthought.

The mature setup isn't "all or nothing." It's a reliable paid primary with a public fallback — point your app at a paid endpoint, list a public one as backup, and wrap both in retry-with-backoff and failover. You get production reliability with a free safety net. (And if your volume gets big enough, the next question becomes run your own node vs. keep paying a provider — a different math problem entirely.)

A note on how you pay

Not all paid RPC is the same, either. Most providers bill by "compute units" or "API credits" — opaque per-call pricing where a single eth_getLogs might cost 10–100× a simple eth_blockNumber, making your bill impossible to predict until it arrives. The alternative is flat-rate: a fixed monthly price regardless of which methods you call.

SwiftNodes is flat-rate across Ethereum, Base, and dozens of other chains — dedicated capacity, at-tip data, archive and debug included, and a bill that doesn't surprise you. Use free public RPC to build and learn; when you ship something real, point it at swiftnodes.io — there's a free tier to start, and the pricing stays predictable as you grow.