How to Choose a Solana RPC Provider
Choosing an RPC provider depends on what you are building. A portfolio tracker has different needs than a trading bot. This guide covers the factors that matter and how to evaluate providers.
What to evaluate
1. Latency
The time between sending a request and receiving a response. For reading data, latency affects user experience. For sending transactions, it directly affects landing rate — every millisecond counts when competing for block space.
How to test: Send 100 getSlot requests from your deployment region and measure p50 and p99 response times.
2. Rate limits
Providers limit requests per second, compute units per second, or total monthly requests. Exceeding limits returns 429 errors.
| Pricing model | How limits work |
|---|---|
| Credit/CU-based | Each method costs credits; heavy methods cost more |
| Request-based | Fixed requests per second, all methods equal |
| Flat rate | Fixed monthly price, no per-request metering |
Flat-rate pricing is predictable and avoids surprise bills from traffic spikes.
3. Staked connections
RPC providers with staked connections get preferential treatment through Stake-Weighted QoS (SWQoS). This is the single most important factor for transaction landing rate. Without staked connections, your transactions compete for only 20% of a leader’s capacity.
4. Method support
Not all providers support every method. Check for:
getProgramAccounts(often limited or blocked)- WebSocket subscriptions
- gRPC (Yellowstone) access
sendTransactionwith staked forwarding
5. Geographic coverage
Solana validators are concentrated in specific regions. An RPC node close to validators reduces latency for transaction sending. For reading, a node close to your users reduces response time.
6. Reliability and support
Uptime guarantees (SLA), monitoring dashboards, and support responsiveness matter for production workloads. Some providers offer direct Telegram or Discord support; others use ticket systems with longer response times.
Provider types
| Type | Best for | Typical cost |
|---|---|---|
| Public RPC | Development, testing | Free |
| Shared RPC (paid) | Production apps, moderate traffic | $50-500/mo |
| Dedicated node | High-throughput, trading bots | $500-3,000/mo |
| Self-hosted | Maximum control, custom configuration | $1,000-5,000/mo (hardware) |
Decision framework
Building a dApp or portfolio tracker? A shared RPC plan with good rate limits and WebSocket support is sufficient. Prioritize developer experience and documentation.
Running a trading bot or MEV strategy? You need staked connections, low latency, and possibly a dedicated node. Prioritize transaction landing rate and geographic proximity to validators. Consider providers like Supanode that offer staked infrastructure: https://supanode.xyz/pricing.
Indexing or analytics?
You need getProgramAccounts support, high rate limits, and possibly gRPC for real-time data. Consider dedicated nodes or specialized data providers.
FAQ
Can I use the public RPC for production? Not recommended. The public endpoint has strict rate limits, no SLA, and no staked connections. It is designed for development and light testing.
How many providers should I use? At least two for redundancy. Send transactions to multiple endpoints. Use a primary provider for reads with a fallback.
What is the cheapest option for a new project? Start with a free tier from a paid provider (better than the public RPC). Upgrade when you hit rate limits or need better landing rate.
Do I need gRPC? Only if you need real-time streaming of account updates, transaction data, or block notifications. For standard request-response patterns, HTTP RPC is sufficient.
Sources
Updated: