Choose an RPC provider with a workload test, not a universal speed ranking. The same endpoint can perform well for small account reads and poorly for large program scans. This guide defines an evaluation you can rerun when your traffic changes.
Solana Tracker provides RPC services. The method below is provider-independent; it does not claim a measured winner. For a vendor shortlist, see the Solana RPC provider guide.
Write an acceptance contract before testing
List the methods, deployment regions, peak concurrency, expected response sizes, history depth, and commitment levels your product requires. Add recovery requirements for streams and an error budget for timeouts and throttling.
A provider that lacks a required method fails the evaluation regardless of its getBalance latency. Likewise, an inexpensive tier is not viable if its per-method limit blocks the product's normal traffic.
Use a reproducible workload manifest
{
"region": "your-production-region",
"commitment": "confirmed",
"warmupRequests": 20,
"measuredRequests": 500,
"concurrency": [1, 5, 20],
"timeoutMs": 5000,
"methods": ["getBalance", "getMultipleAccounts", "getLatestBlockhash"]
}These are example test settings, not service limits. Use public test accounts and a fixed account set for each run. Add your actual heavy methods and representative payloads. Avoid live transaction sends in a read benchmark.
Record failures and freshness with latency
For every attempt, record method, start time, elapsed duration, result class, returned context slot when available, and response size. Redact endpoint credentials. Store failures separately but include their count in the denominator.
| Result | What it tells you |
|---|---|
| Low median, high p99 | Occasional stalls still affect users |
| Fast response, stale context | Low latency is hiding old state |
| High 429 rate | Workload exceeds a service or method limit |
| Fast small reads, slow scans | Capacity differs by method and payload |
| Stable reads, frequent stream gaps | The streaming path needs a separate review |
Do not compare a cached result from one provider against an uncached result from another without noting the difference. Alternate providers during the same test window to reduce time-of-day bias.
Test stream recovery deliberately
Run the same filter on each stream. Record received slots, reconnect count, processing backlog, and how you recover a controlled disconnect. A long-lived connection with an ever-growing consumer queue is not a healthy stream.
Check whether replay or historical recovery exists for your subscription and plan. If not, design a backfill process before depending on the feed for accounting or alerts.
Normalize monthly cost against method mix
Estimate monthly requests per method, multiply by the documented credit weight, and include subscription, bandwidth, overage, and dedicated infrastructure costs where applicable. Report the assumptions alongside the estimate.
For example, a larger getMultipleAccounts request can replace several small reads but consume different provider resources. Compare the final workload, not only a headline price per million requests.
Select and migrate
Choose the lowest-cost option that meets the acceptance contract with room for growth. Keep a second provider operational if availability requires it, and test fallback behavior rather than merely storing a backup URL.
Start with shadow reads, compare responses, and gradually increase traffic. Inventory provider-specific methods such as indexed lookup-table discovery before assuming an endpoint swap is sufficient.
FAQ
What makes an RPC provider high performance?
Predictable latency, freshness, method support, and recovery under your workload. No single speed number captures all four.
Should I buy dedicated capacity first?
Use it when measurements or isolation requirements justify it. A shared endpoint may satisfy a smaller workload.
How often should I rerun the benchmark?
After material changes to traffic, region, method mix, provider tier, or application latency requirements.