---
title: Choosing an RPC Provider
description:
  Compare Solana RPC providers by method coverage, history, limits, regions,
  reliability, and operational fit.
url: /docs/rpc/providers
type: guide
prerequisites:
  - /docs/rpc
related:
  - /docs/references/clusters
  - /docs/rpc/http
  - /docs/rpc/websocket
---

An RPC provider gives your application an HTTP endpoint for requests and,
usually, a WebSocket endpoint for subscriptions. The public Solana endpoints are
useful for development, but production applications should use private RPC
access with capacity and support that match their traffic.

Use the [Solana RPC infrastructure directory](/rpc) to find current free,
shared, and dedicated services. The directory changes as providers and their
offerings change; this guide explains how to compare them.

## Start with your workload

Measure or estimate the workload before comparing plans:

- clusters you need: Mainnet, Devnet, or Testnet
- peak requests per second, not only the daily average
- HTTP methods, WebSocket subscriptions, and concurrent connections
- response size and bandwidth, especially for account and block queries
- how far back you need transaction, signature, and block history
- where your users and backend services run
- whether you submit transactions, read data, or do both

A wallet balance view, an indexer, and a transaction service have different
bottlenecks. Test with representative requests and response sizes instead of a
single lightweight method.

## Compare provider capabilities

| Area                 | Questions to ask                                                                                                                               |
| -------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
| Standard RPC         | Is every required [HTTP](/docs/rpc/http) and [WebSocket](/docs/rpc/websocket) method available? Are any methods disabled or priced separately? |
| History              | What is the earliest available slot? Is full transaction history retained, and how are archival requests billed?                               |
| Limits               | What are the request, method, response-size, bandwidth, batch, WebSocket, and concurrent-connection limits?                                    |
| Freshness            | How far behind the cluster can reads be? Are `processed`, `confirmed`, and `finalized` commitments all supported consistently?                 |
| Transaction delivery | Does the service only forward `sendTransaction`, or also provide routing, retries, staked connections, or status tracking?                     |
| Regions              | Can traffic run near your users or backend? Is routing automatic, configurable, or tied to one region?                                         |
| Reliability          | Is there a published SLA, status page, incident history, support path, and maintenance policy?                                                 |
| Access               | Are browser requests allowed? How are API keys scoped, rotated, restricted, and observed?                                                      |
| Portability          | Does the application depend on provider-specific APIs, parsed data, webhooks, or streams beyond standard Solana RPC?                           |
| Cost                 | Which units are billed: requests, method weights, compute credits, response bytes, egress, or dedicated capacity?                              |

Provider-specific APIs can be valuable, but keep the standard RPC boundary
clear. That makes it easier to add a fallback or change providers later.

## Check history and method support

Run the exact methods your application needs against a trial endpoint. These
standard calls provide a useful first check:

```shell title="Inspect an RPC endpoint"
RPC_URL="https://your-provider.example"

curl "$RPC_URL" \
  -H "content-type: application/json" \
  --data '{"jsonrpc":"2.0","id":1,"method":"getVersion"}'

curl "$RPC_URL" \
  -H "content-type: application/json" \
  --data '{"jsonrpc":"2.0","id":1,"method":"getHealth"}'

curl "$RPC_URL" \
  -H "content-type: application/json" \
  --data '{"jsonrpc":"2.0","id":1,"method":"minimumLedgerSlot"}'

curl "$RPC_URL" \
  -H "content-type: application/json" \
  --data '{"jsonrpc":"2.0","id":1,"method":"getFirstAvailableBlock"}'
```

`minimumLedgerSlot` reports the lowest slot retained in the node's ledger, while
`getFirstAvailableBlock` reports the lowest confirmed block slot that has not
been purged. Neither alone guarantees that every historical method or
transaction is available, so test a known old signature or block from your
required range.

Also test error responses. Confirm how the service reports rate limiting, method
restrictions, oversized responses, timeouts, and invalid API keys.

## Measure latency and freshness

Latency includes network distance, provider routing, queueing, and the time
needed to execute a method. Measure at least:

- median and tail latency, such as p95 and p99
- error and timeout rates at normal and peak load
- returned slot compared with another healthy endpoint
- time from sending a transaction to observing its signature status
- WebSocket reconnect time and missed-notification recovery

Run measurements from the same regions as the application. A fast response from
a lagging node can still give users stale state.

## Plan for failures

For production traffic, decide what happens when an endpoint becomes slow,
rate-limited, stale, or unavailable.

1. Configure timeouts, bounded retries, and backoff with jitter.
2. Maintain at least one separately operated fallback for critical paths.
3. Health-check both availability and slot freshness before routing traffic.
4. Keep related blockhash, simulation, send, and confirmation operations on a
   healthy endpoint when possible; lag between endpoints can produce confusing
   results.
5. Re-establish WebSocket connections and subscriptions after disconnects.
   Subscription notifications are not a durable event log, so reconcile state
   with HTTP after reconnecting.

Do not retry every request blindly. Reads are generally safe to retry, but a
timed-out transaction submission may already have reached the cluster. While its
recent blockhash remains valid, reuse the same signed transaction and track its
signature instead of creating a new payment or state change. After the blockhash
expires, search transaction history for the original signature or verify the
intended change against reliable application or onchain state. A `null` result
from the recent signature-status cache is inconclusive. Only rebuild with a
fresh blockhash after establishing that the original did not land. A rebuilt
transaction has a new signature, so preserve application-level idempotency
before sending it.

## Protect access credentials

Treat paid RPC URLs and API keys as credentials. Keep unrestricted keys out of
source control, logs, analytics, and public client bundles. If a browser or
mobile client must call RPC directly, use a restricted public key or a backend
proxy and enforce origin, method, and rate limits where the provider supports
them.

An RPC endpoint never needs a wallet's private key or seed phrase. Transactions
sent through `sendTransaction` are already signed.

## Selection checklist

Before committing to a provider or architecture, confirm:

- required clusters, methods, commitments, and historical range work
- sustained and burst traffic fit documented limits
- latency, freshness, and error rates meet targets from every required region
- WebSocket reconnect and reconciliation behavior is tested
- keys can be scoped, rotated, and monitored
- pricing has been modeled with representative heavy methods and responses
- alerts, support, status information, and escalation paths are documented
- a fallback has been tested instead of only configured

Re-run the evaluation as traffic and RPC usage change. The best provider fit is
an operational decision, not a permanent property of an application.