How do Solana RPC providers differ in rate limiting and throughput?

Solana's high throughput makes RPC capacity a real engineering constraint. Unlike EVM chains where a simple eth_call is cheap, Solana RPC requests vary enormously in cost: a getBalance call is trivial, while getProgramAccounts or a busy WebSocket subscription can consume a large share of a node's resources. That is why "rate limiting" on Solana is not a single number you can compare across providers. It is a combination of request-per-second caps, method-level restrictions, compute-unit accounting, and connection limits.

This article explains the rate-limiting models you will encounter, what to check before committing to a provider, and how to decide between shared and dedicated capacity for your workload.

Quick recommendation: shared tier or dedicated node?

Before comparing providers line by line, decide which capacity model fits your app.

• Prototyping, low-volume dApps, or read-only dashboards: a shared RPC tier is usually enough. You get a managed endpoint with a published or soft rate limit, and you do not manage infrastructure.
• Trading bots, indexers, wallet backends, or anything with bursty or sustained load: shared tiers will eventually throttle you. A dedicated node gives you a predictable ceiling and removes the shared-pool contention that causes latency spikes.
• Heavy getProgramAccounts, getSignaturesForAddress scans, or large WebSocket fan-out: these are the calls most likely to be restricted on shared tiers. If your app depends on them, plan for dedicated capacity or an indexing layer.

If you are unsure, start on a shared endpoint, instrument your request patterns, and move to dedicated capacity when you see throttling or latency variance. OnFinality offers both models, so you can scale without changing providers. See RPC pricing for how the tiers map to usage.

The four rate-limiting models you will actually encounter

Providers rarely publish a single "requests per second" figure. Most combine several mechanisms:

1. Requests per second (RPS) or per minute (RPM). The simplest cap. Applied per API key or per IP. Fine for steady traffic, punishing for bursts.
2. Compute-unit (CU) accounting. Each method is assigned a cost. A getBalance might cost 1 CU while getProgramAccounts costs hundreds or thousands. Your plan is a CU budget, not a request count. This is the model most aligned with how Solana nodes actually consume resources.
3. Method-level restrictions. Some providers block or heavily limit expensive methods on shared tiers, regardless of your CU budget. getProgramAccounts and getProgramAccounts-style scans are the usual suspects.
4. Connection and subscription limits. WebSocket connections, concurrent subscriptions, and accountSubscribe / logsSubscribe counts are often capped separately from HTTP.

When you compare providers, ask which of these four apply and how they interact. A provider with a generous RPS cap but strict CU accounting may throttle you sooner than expected.

Provider evaluation matrix

Use this table to structure your comparison. Fill in the specifics from each provider's current documentation, since limits change over time.

OnFinality provides shared RPC API access and dedicated Solana nodes, so you can match the model to your workload. Compare the two on the Solana network page.

Solana-specific limits that trip up comparisons

Generic RPC comparisons often ignore Solana's method economics. Three areas deserve special attention.

getProgramAccounts and account scans

getProgramAccounts can return enormous result sets. Many providers either disable it on shared tiers, require a dataSlice or filters, or charge a high CU cost. If your app relies on it, confirm the policy before you commit. A provider that "supports Solana" but silently rate-limits this method will break your indexer.

WebSocket subscriptions

Solana apps frequently use accountSubscribe, logsSubscribe, and slotSubscribe. These hold server resources for the life of the connection. Providers cap concurrent subscriptions per key, and a busy subscription can be throttled independently of your HTTP traffic. Test subscription limits under realistic load, not just with a single connection.

Transaction submission and priority fees

sendTransaction behavior varies. Some providers forward transactions to leaders with different strategies, and some apply separate limits to write-path calls. If you submit transactions at volume, ask how the provider handles submission and whether it affects your rate budget.

Testing a provider's limits before you commit

Do not rely on published numbers alone. Run a short load test against your candidate endpoints and watch for the shape of the throttling.

A minimal probe using curl against the OnFinality public Solana endpoint:

curl https://solana.api.onfinality.io/public \
  -X POST -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"getSlot","params":[]}'

For a quick throughput check in JavaScript, fire a batch of cheap calls and measure how the provider responds as you increase concurrency:

const endpoint = "https://solana.api.onfinality.io/public";

async function probe(concurrency) {
  const calls = Array.from({ length: concurrency }, (_, i) =>
    fetch(endpoint, {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({
        jsonrpc: "2.0",
        id: i,
        method: "getSlot",
        params: [],
      }),
    }).then((r) => r.status)
  );
  const results = await Promise.all(calls);
  const throttled = results.filter((s) => s === 429).length;
  console.log(`concurrency=${concurrency} throttled=${throttled}`);
}

probe(10);
probe(50);
probe(100);

Watch for HTTP 429 responses, JSON-RPC error codes, and rising latency. The concurrency level where throttling begins is your practical ceiling on that tier. Repeat against a dedicated endpoint to see the difference.

Reading throttling signals correctly

When you hit a limit, the symptom tells you which mechanism fired:

Distinguishing these cases prevents the common mistake of upgrading a plan when the real fix is batching or filtering your calls.

Reducing your rate-limit footprint

Before paying for more capacity, cut unnecessary load:

• Batch JSON-RPC requests where the provider supports it, so many cheap calls share one HTTP round trip.
• Use dataSlice and filters on getProgramAccounts to shrink result sets.
• Cache aggressively. Slot heights, token metadata, and account data change less often than you might poll.
• Prefer WebSocket subscriptions over polling for state that changes frequently, but cap the number of subscriptions.
• Separate read and write paths so a burst of transaction submissions does not starve your read traffic.

These changes often delay the need for a higher tier and make your usage more predictable.

When dedicated capacity is the right answer

Shared tiers are economical and fine for many apps. Dedicated nodes make sense when:

• You need a predictable throughput ceiling that does not vary with other tenants.
• You rely on heavy methods or large WebSocket fan-out that shared tiers restrict.
• You want to run archive-style queries or index historical data.
• You need consistent latency for trading or real-time UX.

OnFinality's dedicated node option gives you a private Solana node while keeping the managed operational model. You can review supported networks on the networks page and compare costs on RPC pricing.

Key Takeaways

• Solana rate limiting is not one number; it combines RPS/RPM caps, compute-unit accounting, method restrictions, and WebSocket limits.
• getProgramAccounts, signature scans, and subscriptions are the calls most likely to be throttled on shared tiers.
• Always load-test candidate endpoints and read the throttling signals before committing.
• Reduce your footprint with batching, filters, caching, and subscriptions before upgrading.
• Move to a dedicated node when you need predictable throughput, heavy-method support, or consistent latency.

Frequently Asked Questions

Can I compare Solana RPC providers by requests per second alone? No. RPS is only one mechanism. Compute-unit accounting and method-level restrictions often matter more, especially for heavy calls like getProgramAccounts.

Why do I get 429 errors only on some methods? That usually indicates a method-level restriction rather than a global RPS cap. Add filters or dataSlice, or move those calls to a dedicated node.

Do WebSocket subscriptions count against my rate limit? Often yes, but separately from HTTP. Providers typically cap concurrent connections and subscriptions per key.

How do I know when to switch from shared to dedicated? When you see sustained throttling, latency variance from shared-pool contention, or you depend on methods restricted on shared tiers.

Does OnFinality offer both shared and dedicated Solana access? Yes. OnFinality provides shared RPC API endpoints and dedicated Solana nodes, so you can start shared and scale to dedicated without changing providers. See RPC pricing and the Solana network page.

Next steps

Start by mapping your actual request patterns: which methods, how often, and how bursty. Then test a shared endpoint against your peak load. If it holds, you are done. If it throttles, you now know whether the fix is batching, filtering, or dedicated capacity. OnFinality supports both models, and you can review supported RPC networks to plan your rollout.