Every Web3 project starts with a free RPC endpoint. You grab a public URL from a chain's docs, paste it into your config, and ship. That works fine until users complain about failed transactions, your indexer falls behind, or you hit a rate limit at the worst possible time.
The question isn't whether to upgrade—it's when. This guide breaks down what you get from free endpoints, where they fall short, and how to evaluate paid providers when the time comes.
What Public Endpoints Actually Offer
Public RPC endpoints are free nodes operated by blockchain foundations, ecosystem grants, or infrastructure companies offering limited free tiers. They're a public good, and they're genuinely useful for:
The tradeoffs are predictable: rate limits (typically 10–100 req/s), no uptime guarantees, shared infrastructure that slows under network-wide load, and limited method support (usually no archive data, no debug_ or trace_ calls, spotty WebSocket reliability).
If your application can tolerate occasional 503s and you're not running time-sensitive transactions, public endpoints are fine indefinitely.
When Free Stops Working
You'll know it's time to upgrade when you hit one of these walls:
Production Traffic
A 10-minute RPC outage during a token launch or NFT mint costs real money. Paid providers offer 99.9%+ uptime SLAs, redundant infrastructure across regions, and incident response teams. Free endpoints offer none of that—you're on your own when things break.
Throughput Limits
Free endpoints cap you at 10–100 requests per second. A single user refreshing a DeFi dashboard might generate 5–10 calls; scale to 1,000 concurrent users and you'll blow past limits instantly. Symptoms: intermittent failures, HTTP 429 errors, users reporting "stuck" transactions.
Archive Data Requirements
Most free endpoints only serve recent state (the last 128–256 blocks on Ethereum, for example). If you need historical balances, old transaction receipts, or state at arbitrary block heights—for analytics, compliance, or DeFi protocol logic—you need archive node access. That's a paid feature everywhere.
WebSocket Reliability
Real-time applications (trading interfaces, live dashboards, event-driven bots) depend on persistent WebSocket connections for eth_subscribe and similar methods. Free WebSocket endpoints tend to drop connections under load and lack the infrastructure for stable long-lived streams.
Trace and Debug Methods
Deep transaction analysis (debug_traceTransaction, trace_call, trace_block) requires specialized node configurations. These methods are computationally expensive, and free endpoints almost never expose them.
Support
When your RPC calls start failing at 2 AM and you can't figure out why, you want a support channel. Paid providers offer Slack/Discord access, dedicated account managers on enterprise tiers, and priority incident response.
Pricing Models: Flat-Rate vs Compute Units
Paid providers use two main billing approaches, and understanding them matters for budgeting.
Flat-Rate / Request-Based Pricing
You pay a fixed monthly fee for a set number of requests (or responses). Every RPC call counts as one, regardless of method complexity.
Upside: Predictable costs. You know exactly what you'll spend, and finance teams love that.
Downside: If you exceed your allocation, overages kick in—sometimes at steep per-request rates.
Providers using this model: Dwellir (1 response = 1 credit across all methods) and Chainstack (1 request unit for full node calls, 2 RUs for archive).
Compute Unit Pricing
Different methods consume different amounts of "compute units" (CUs) based on their resource intensity. A simple eth_chainId might cost 5 CUs; eth_getLogs with a wide block range might cost 75+; debug_traceTransaction can hit 500+.
Upside: You pay proportionally for heavy operations, which can be cheaper if your workload is mostly lightweight calls.
Downside: Costs are hard to predict without detailed usage analytics. A change in your application's call patterns can blow up your bill unexpectedly.
Providers using this model: Alchemy, QuickNode, Infura, and dRPC (each with different CU weights and pricing tiers).
Which Model Fits?
If your workload mixes many method types (standard calls, logs, traces, archive lookups), flat-rate pricing removes the mental overhead of tracking CU consumption. If you're running a simple dApp with predictable, lightweight calls, CU pricing might edge out slightly cheaper—but you'll need to monitor it closely.
Evaluating Providers: What to Check
When comparing paid options, focus on these factors:
| Factor | Questions to Ask |
|--------|-----------------|
| Uptime SLA | Is 99.9% guaranteed? What's the compensation if they miss it? |
| Throughput | What's the sustained RPS? Burst limits? |
| Latency | Where are nodes located? What's typical p50/p99 latency for your region? |
| Archive Access | Included or extra cost? How far back? |
| WebSocket Support | Stable connections? eth_subscribe supported? |
| Trace/Debug Methods | Available on standard plans or enterprise-only? |
| Chain Coverage | Do they support all networks you need now and might need later? |
| Pricing Clarity | Can you accurately predict monthly costs from your usage patterns? |
| Support | Response time commitments? Dedicated channels for paid tiers? |
Making the Transition
When you're ready to move off public endpoints:
The Bottom Line
Public RPC endpoints are a legitimate choice for development, learning, and low-stakes applications. They're free, easy, and often good enough.
But "good enough" has a ceiling. Once you're running production traffic, need archive data, depend on real-time WebSocket streams, or simply can't afford downtime, upgrading to a paid provider becomes table stakes for reliability.
The transition doesn't have to be expensive—free tiers from providers like Alchemy, Infura, QuickNode, and Dwellir let you scale significantly before paying anything. When you do start paying, predictable pricing models (flat-rate, request-based) make budgeting straightforward.
Browse RPC Directory to compare providers, check pricing calculators, and find the right fit for your workload.