Can you compare Solana RPC providers in terms of their rate limiting and throughput?

How to compare Solana RPC rate limits without guessing

Most Solana RPC comparisons stop at "requests per second." That number is real, but it hides the parts that actually break production apps: which methods are metered, whether bursts are allowed, how WebSocket subscriptions are counted, and what happens when you cross the line. Before you pick a provider, decide which of these three profiles matches your workload.

• Light interactive app (wallet, dashboard, a few hundred users): a shared endpoint with a per-second request cap is usually enough. Optimize for predictable cost and simple failover.
• Indexer or analytics job (backfills, getSignaturesForAddress, getProgramAccounts): method-level or compute-unit metering matters more than raw RPS, because heavy calls consume disproportionate capacity.
• Trading or real-time service (WebSocket subscriptions, tight confirmation loops): you need to know how subscriptions are billed and whether you can get a dedicated node to remove shared-pool contention.

If you can name your profile, the rest of the comparison is mechanical. If you cannot, start by measuring your current request mix — the monitoring section below shows how.

The rate-limiting models you will actually encounter

Solana RPC providers generally meter traffic in one of four ways, and many combine two.

1. Per-second request cap (RPS). A flat ceiling on requests per second, sometimes with a short burst allowance. Simple, but a single expensive call can consume the same "slot" as a cheap one.
2. Per-method limits. Specific methods (often getProgramAccounts, getSignaturesForAddress, getTransaction) have their own lower ceilings because they are expensive to serve.
3. Compute-unit or credit metering. Each method is assigned a cost weight; your plan grants a budget per second or per month. This is the fairest model for mixed workloads but the hardest to predict without tooling.
4. Connection and subscription limits. Caps on concurrent WebSocket connections, subscriptions per connection, or both. Easy to overlook until your real-time feed silently drops.

A provider that advertises a high RPS number but applies tight per-method limits can feel slower than one with a lower headline rate and generous method budgets. Always ask for the method-level breakdown, not just the top-line number.

Provider evaluation matrix

Use this table as a checklist when you talk to any Solana RPC provider, including OnFinality. The right-hand column is what to do with the answer.

OnFinality offers shared Solana RPC through its Solana network page and dedicated Solana nodes through dedicated node infrastructure when shared limits no longer fit. Compare that against other providers using the same rows above so the decision is like-for-like.

What each Solana method costs you

Not every JSON-RPC call is equal. The table below groups common Solana methods by how much pressure they put on a shared endpoint. Treat it as a planning guide, not a fixed price list — exact weights vary by provider.

The practical takeaway: if your workload is dominated by the bottom three rows, a shared endpoint with per-method caps will constrain you long before your RPS ceiling does. That is the clearest signal to evaluate a dedicated node.

Measure your real headroom before you switch

Do not compare providers on marketing numbers. Measure your own traffic first, then compare. A small probe that records latency and error codes will tell you where you actually sit.

// Minimal Solana RPC probe: latency + error sampling
const ENDPOINT = "https://solana.api.onfinality.io/public";

async function probe(method, params = []) {
  const start = Date.now();
  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();
  return {
    method,
    status: res.status,
    ms: Date.now() - start,
    error: body.error?.code ?? null,
  };
}

(async () => {
  const calls = [
    ["getLatestBlockhash", []],
    ["getBalance", ["11111111111111111111111111111111"]],
  ];
  for (const [m, p] of calls) console.log(await probe(m, p));
})();

Run this against your current endpoint and against a candidate endpoint under the same conditions. Track three signals: median latency, the rate of HTTP 429 responses, and JSON-RPC error codes such as -32005 (node is behind or rate-limited). A rising 429 rate at steady traffic is the earliest sign you are near a ceiling.

For a quick manual check, a single curl call confirms connectivity and response shape:

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

A healthy endpoint returns {"jsonrpc":"2.0","result":"ok","id":1}. If you see errors here, the problem is connectivity or the endpoint itself, not your rate limit.

WebSocket subscriptions and their hidden budget

Real-time Solana apps lean on WebSocket subscriptions, and this is where rate-limit comparisons most often go wrong. Two providers can advertise the same HTTP RPS but treat subscriptions completely differently.

• Some count each subscription against your request budget; others count each delivered message.
• Some cap concurrent connections; others cap subscriptions per connection.
• Reconnect behavior matters: if a provider drops idle connections aggressively, your client may resubscribe constantly and burn budget.

When you evaluate a provider, ask specifically how accountSubscribe, logsSubscribe, and slotSubscribe are metered, and whether the WebSocket endpoint shares a budget with HTTP. OnFinality exposes both HTTP and WebSocket transports for Solana; the exact endpoints are listed on the Solana network page.

When a shared endpoint stops being enough

There is a point where tuning your client no longer helps and the shared pool itself is the constraint. Watch for these signals:

• 429 responses appear at your normal traffic level, not just during spikes.
• getProgramAccounts or backfill jobs consistently fail or time out.
• WebSocket subscriptions disconnect under load and resubscribe loops begin.
• Your provider's per-method caps are lower than your steady-state need for one or two methods.

At that point, the comparison shifts from "which shared plan" to "shared vs dedicated." A dedicated Solana node gives your workload its own capacity instead of sharing a pool, which removes contention from other tenants. It is not automatically cheaper, so weigh it against the cost of engineering around shared limits. See RPC pricing for plan shapes and dedicated node infrastructure for the dedicated option.

A migration checklist for switching Solana RPC providers

If you decide to move, do it in a controlled way rather than a hard cutover.

1. Inventory your methods. List every JSON-RPC method and subscription your app uses, with approximate call volume.
2. Map volume to the new metering model. Convert your mix into the candidate provider's units (RPS, method caps, or credits) so you compare like for like.
3. Run both endpoints in parallel. Send a percentage of read traffic to the new endpoint and compare latency and error rates.
4. Add failover. Configure a secondary endpoint and switch on 429s or connection errors rather than failing the request.
5. Re-test heavy jobs. Run a getProgramAccounts or backfill job against the new endpoint before you rely on it.
6. Cut over writes last. Move sendTransaction traffic only after reads are stable, and keep the old endpoint as a fallback briefly.

Keep the parallel-run window long enough to cover a full traffic cycle, including your busiest hour.

Key Takeaways

• Solana RPC rate limiting is rarely just RPS; per-method caps, compute-unit metering, and subscription limits usually decide what you can run.
• Expensive methods like getProgramAccounts and getSignaturesForAddress are the most common cause of throttling, not raw call volume.
• Measure your own latency, 429 rate, and JSON-RPC error codes before comparing providers on headline numbers.
• Ask how WebSocket subscriptions are metered, because real-time apps can exhaust a plan through subscriptions alone.
• When shared limits become the constraint, a dedicated Solana node removes shared-pool contention; compare it against the cost of engineering around the limits.
• OnFinality provides shared Solana RPC and dedicated Solana nodes; start from the Solana network page, RPC pricing, and the full list of supported RPC networks.

Frequently Asked Questions

Do all Solana RPC providers use the same rate-limiting model? No. Some use a flat requests-per-second cap, some apply per-method limits, and some use compute-unit or credit metering. Many combine two or more. The model matters more than the headline number because it determines which of your calls gets throttled first.

Why does my app hit limits even though my request rate is low? Usually because a few expensive methods dominate your usage. Calls like getProgramAccounts and getSignaturesForAddress can consume far more capacity than their request count suggests, so a low overall rate can still trigger per-method caps.

Are WebSocket subscriptions counted against the same limit as HTTP calls? It depends on the provider. Some count subscriptions or delivered messages against your budget, and some cap concurrent connections instead. Ask before you commit, especially for real-time apps.

When should I move from a shared Solana endpoint to a dedicated node? When 429s appear at normal traffic levels, heavy methods consistently fail, or WebSocket subscriptions drop under load. At that point the shared pool is the constraint, and a dedicated node gives your workload its own capacity.

How do I test a new Solana RPC provider before switching? Run both endpoints in parallel, send a share of read traffic to the new one, and compare latency, 429 rate, and JSON-RPC error codes. Re-test your heaviest jobs, then move write traffic last with failover in place.

Can I use OnFinality for Solana RPC? Yes. OnFinality offers shared Solana RPC and dedicated Solana nodes. See the Solana network page for endpoints and RPC pricing for plan details.