A Solana RPC benchmark should answer one question: will this endpoint hold up for your actual app?
That means you should not test only one getBalance request from your laptop. You need to test the methods your app uses, from the server region your app uses, long enough to catch throttling, disconnects, and p95 or p99 latency.
For provider recommendations, use Solana RPC Providers Compared 2026. This guide is the testing plan to run before you buy.
The Minimum Useful Benchmark
A useful benchmark includes reads, writes, and subscriptions.
| Test | Why it matters |
|---|---|
| getLatestBlockhash | Shows basic latency and freshness |
| getBalance | Cheap baseline request |
| getAccountInfo | Common app and bot read path |
| getProgramAccounts | Heavy query that exposes provider limits quickly |
| simulateTransaction | Matters before sending user or bot transactions |
| sendTransaction | Tests the execution path, not just read latency |
| confirmation polling | Shows how quickly your app can trust state |
| WebSocket or gRPC subscription | Catches disconnects and stale streams |
Test
getLatestBlockhash
- Why it matters
- Shows basic latency and freshness
Test
getBalance
- Why it matters
- Cheap baseline request
Test
getAccountInfo
- Why it matters
- Common app and bot read path
Test
getProgramAccounts
- Why it matters
- Heavy query that exposes provider limits quickly
Test
simulateTransaction
- Why it matters
- Matters before sending user or bot transactions
Test
sendTransaction
- Why it matters
- Tests the execution path, not just read latency
Test
confirmation polling
- Why it matters
- Shows how quickly your app can trust state
Test
WebSocket or gRPC subscription
- Why it matters
- Catches disconnects and stale streams
The benchmark should record status code, provider error message, latency, slot, and whether the response was usable.
Metrics That Matter
Average latency is the vanity metric. It is useful, but it hides the pain.
Track:
- •p50 latency: normal user experience.
- •p95 latency: the slow path users actually notice.
- •p99 latency: the bad tail that breaks bots and dashboards.
- •error rate: failed requests divided by total requests.
- •throttle rate: 429s or provider-specific limit errors.
- •blocked requests: 403s or policy blocks.
- •slot lag: whether the provider is behind the chain.
- •subscription uptime: whether streams stay connected.
- •confirmation time: how quickly sent transactions become usable.
If the provider wins p50 but loses p99, it may feel fast in a demo and fail under pressure.
Test From the Right Place
Benchmark from your deployment region, not your home machine. If your app runs on Vercel, Fly, Railway, AWS, or a private server, run the test close to that environment.
This matters because RPC latency includes network distance. A provider can look bad from one city and solid from another. The only location that matters is where your production traffic originates.
Use Your Real Method Mix
A token dashboard, wallet, NFT app, and trading bot all stress RPC differently.
For a wallet, test balance reads, token account reads, transaction history, transaction send, and confirmation. For a bot, test account subscriptions, blockhash refreshes, transaction simulation, and send paths under burst load. For analytics, test historical queries and any archive data you need.
Then turn that method mix into cost. Providers may bill by request, API credit, compute unit, bandwidth, or plan limit. You cannot compare prices until you know what your app actually calls.
Red Flags
Treat these as warning signs:
- •p99 latency is several times worse than p50.
- •WebSockets disconnect without clean reconnect behavior.
- •Heavy methods throttle quickly.
- •The pricing model makes cost impossible to forecast.
- •Provider docs do not clearly explain limits.
- •Support is too slow for the workload's risk.
- •Transaction sends are fast in calm periods but unreliable under congestion.
None of these automatically disqualify a provider. They tell you what engineering work you will own.
Public RPC Benchmark Warning
Public Solana endpoints are shared infrastructure. Solana's own docs note that public endpoints are not intended for production applications and may return 429s when rate limits are exceeded or 403s when traffic is blocked.
So yes, benchmark public RPC if you want a baseline. But do not treat it as your production option.
Final Verdict
The best Solana RPC provider is the one that wins your actual test, not the one with the cleanest pricing page. Start with Helius, Triton One, QuickNode, Alchemy, and Chainstack depending on workload, then run the same benchmark against each.
If you are building a bot, read Best Solana RPC for Trading Bots. If you are still deciding between public and paid infrastructure, read Public vs Private Solana RPC.
Sources checked
- •Solana public RPC documentation
- •Helius pricing, Sender, and LaserStream documentation
- •Triton One Yellowstone documentation
- •QuickNode pricing and Solana documentation
- •Alchemy compute-unit documentation
- •Chainstack throughput guidance