How do Solana RPC providers handle rate limiting and usage tiers?

Solana RPC is not one product with one set of limits. Every provider wraps the same JSON-RPC surface in its own throttling model, then sells access in tiers. If you are comparing providers, the useful question is not "who has the highest number" but "which limiting model matches how my app actually sends traffic."

This page explains how rate limiting tends to work on Solana RPC, what a usage tier usually controls, and how to choose between a shared endpoint and dedicated node infrastructure. It is written for developers and infrastructure buyers who need to size an endpoint before they ship.

How to decide before you compare tiers

Before you read any provider's tier table, write down three things about your workload: your peak requests per second, the mix of methods you call, and whether you need WebSocket subscriptions. Those three answers eliminate most tiers immediately.

• Low, steady traffic (a wallet, a dashboard, a few thousand calls a day): a shared public or entry tier is usually enough. You care about method availability more than raw throughput.
• Bursty traffic (a mint, a claim window, a bot that wakes up on events): you care about burst allowance and how fast the provider throttles you once you cross it.
• Heavy or continuous traffic (indexers, trading systems, getProgramAccounts scans, log streaming): shared tiers tend to become the bottleneck. This is where dedicated nodes or a private endpoint usually make more sense.

If your app falls into the third group, the tier table is the wrong document to optimize against. Start from capacity instead, and treat shared tiers as a fallback path.

What "rate limiting" actually means on Solana RPC

Providers rarely enforce a single number. In practice you will meet several limit types at once, and the one you hit first is the one that defines your experience.

RPS is the number most providers advertise, but on Solana the compute-unit style budget is often what actually stops you. A single getProgramAccounts call with a broad filter can cost more than hundreds of getSlot calls. If you only compare RPS figures, you can pick a tier that looks generous and still get throttled on your first account scan.

Reading a usage tier without getting surprised

A usage tier is a bundle of four things: a rate allowance, a method set, a transport set, and a support or SLA layer. Providers present them differently, but the underlying questions are the same.

1. Is the rate a hard cap or a soft one? Hard caps return errors immediately. Soft caps may queue or degrade latency first.
2. Which methods are excluded? Archive queries, trace-style calls, and heavy account scans are frequently gated to higher tiers.
3. Is WebSocket included? Subscriptions behave differently from HTTP and are sometimes metered separately.
4. What happens at the limit? A clear error code is easier to handle than silent latency growth.

When you evaluate a tier, ask for the failure behaviour, not just the ceiling. A tier that returns a clean 429 you can back off from is more workable than one that quietly slows every request.

Shared endpoints vs dedicated nodes on Solana

This is the real decision behind the query. Rate limiting exists because shared capacity is finite. Dedicated infrastructure changes the shape of the problem.

OnFinality offers both models for Solana: a shared Solana RPC endpoint for standard workloads, and dedicated node infrastructure when you need reserved capacity and control over your own limits. The right choice depends on whether your ceiling is set by someone else's pool or by your own traffic.

Testing a tier against your real traffic

Do not size a tier from a table. Send representative traffic and watch what happens at the edges. A short load probe against the public endpoint shows you the shape of the response before you commit to a plan.

# Simple RPS probe against the OnFinality Solana public endpoint
ENDPOINT="https://solana.api.onfinality.io/public"

for i in $(seq 1 50); do
  curl -s -o /dev/null -w "%{http_code} %{time_total}s\n" \
    -X POST "$ENDPOINT" \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","id":1,"method":"getSlot","params":[]}'
done

Watch for three signals: non-200 responses, rising time_total, and any JSON-RPC error objects in the body. A clean run at your expected peak tells you the tier fits. Errors or latency growth tell you to move up a tier or move to dedicated capacity.

For method-level testing, probe the calls you actually depend on rather than only getSlot:

// Check whether a heavy method is available on your tier
const endpoint = "https://solana.api.onfinality.io/public";

async function probe(method, params) {
  const res = await fetch(endpoint, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ jsonrpc: "2.0", id: 1, method, params }),
  });
  const body = await res.json();
  console.log(method, res.status, body.error ?? "ok");
}

await probe("getSlot", []);
await probe("getVersion", []);

If a method returns a method-not-found or rate error on your tier, that is a tier boundary, not a bug. Record it and factor it into your plan.

Failure signals and what they mean

When a Solana RPC endpoint starts refusing work, the symptom tells you which limit you hit.

Treat these as design inputs. If your app regularly trips the same limit, the tier is the wrong shape for the workload, and no amount of retry logic will fix the underlying mismatch.

Designing around limits instead of fighting them

Good Solana clients assume limits exist. A few habits reduce how often you hit them:

• Batch where the API allows it. JSON-RPC batch requests reduce round trips and RPS pressure.
• Cache what does not change. Slot height, epoch info, and static account data do not need a call per request.
• Use WebSocket subscriptions for state changes instead of polling in a loop.
• Separate workloads by key. Keep indexer traffic away from user-facing traffic so one does not starve the other.
• Add a fallback endpoint. A second provider or a dedicated node gives you a path when the primary throttles.

These patterns are provider-agnostic. They also make tier comparisons easier, because you are comparing your optimized traffic against each tier rather than your worst-case burst.

Key Takeaways

• Solana RPC rate limiting is usually a mix of RPS caps, compute-unit budgets, per-method limits, and connection limits, not a single number.
• A usage tier bundles a rate allowance, a method set, a transport set, and a support layer; the failure behaviour matters as much as the ceiling.
• Heavy methods like account scans are often the real constraint, so compare method support, not just RPS.
• Shared endpoints suit wallets, dashboards, and moderate apps; dedicated nodes suit indexers, trading systems, and continuous high-volume backends.
• Test a tier with representative traffic and watch for 429s, latency growth, and method errors before you commit.
• OnFinality provides both a shared Solana RPC endpoint and dedicated node options, with details on RPC pricing and supported RPC networks.

Frequently Asked Questions

Do all Solana RPC providers rate limit the same way? No. Most combine RPS caps with weighted method costs and connection limits, but the exact model and the point at which you get throttled differ. Compare failure behaviour, not just headline numbers.

Is a higher usage tier always the right fix? Only if your workload fits a shared model. If you run continuous heavy traffic or frequent account scans, dedicated capacity is often the better fit than climbing tiers.

How do I know which limit I hit? Look at the symptom. Immediate errors across all calls usually mean an RPS cap. Errors only on heavy methods point to a compute budget or per-method cap. Latency growth without errors suggests a soft throttle or shared contention.

Can I avoid rate limits entirely? No endpoint is unlimited. You can reduce how often you hit limits by batching, caching, using WebSocket subscriptions, and separating workloads, and you can raise your ceiling with dedicated infrastructure.

Does OnFinality support Solana WebSocket? Yes. The Solana endpoint supports HTTP and WebSocket transports. See the Solana network page for the current endpoint details and RPC pricing for plan options.

Next steps

If you are still comparing providers, start with the workload questions at the top of this page and map your answers to a tier. If your traffic is continuous or method-heavy, evaluate dedicated node capacity instead of chasing a higher shared tier. For endpoint details, plan options, and the full network list, see Solana RPC, RPC pricing, and supported RPC networks.