How do you compare Solana RPC providers on rate limits and throughput?

Yes, you can compare Solana RPC providers on rate, but the useful comparison is not a single number. "Rate" on Solana spans several different limits that interact: requests per second, compute units consumed per request, response size caps, concurrent WebSocket subscriptions, and how the provider treats bursts and historical calls. A provider that looks generous on one axis can throttle you on another.

This page shows you how to compare providers on the metrics that actually affect production apps, how to read published limits without being misled, and how to test limits safely. It also explains when a shared RPC API is the right fit and when a dedicated Solana node is worth the move. You can review OnFinality's Solana RPC API and dedicated node options alongside any other provider using the same criteria.

Quick recommendation: which rate model fits your workload

Before you compare vendors, classify your workload. The right provider depends far more on your traffic shape than on a headline RPS figure.

If your app is bursty but not sustained, a shared RPC API with clear burst behavior is usually enough. If you run continuous high-volume reads or need predictable latency, a dedicated node removes the shared-pool variable. You can compare plans on the RPC pricing page and check coverage on supported RPC networks.

The five rate dimensions that actually matter

When someone asks whether you can compare Solana RPC providers "regarding their rate," they usually mean one of these five things. Compare all five, not just the first.

1. Request rate (RPS or RPM). How many calls per second or minute the endpoint accepts before it returns HTTP 429 or a JSON-RPC error. This is the number most providers publish.
2. Compute units per request. Solana charges compute units per instruction, and some providers meter by compute rather than raw call count. A single heavy getProgramAccounts call can cost far more than hundreds of light getAccountInfo calls.
3. Response size and payload caps. Large account scans or transaction histories can hit payload limits even when your request rate is low.
4. Concurrency and WebSocket subscriptions. How many simultaneous connections and accountSubscribe or logsSubscribe streams you can hold open.
5. Burst behavior. Whether short spikes above your plan are absorbed, queued, or rejected outright.

A provider with a modest RPS but generous compute and burst handling can outperform a provider with a high RPS and strict per-call metering. That is why a single "rate" comparison is rarely enough.

How to read a provider's published limits

Published limits are a starting point, not a guarantee. Read them with these questions in mind:

• Is the limit expressed per second, per minute, or per billing cycle?
• Does the limit apply per API key, per IP, or per project?
• Are heavy methods like getProgramAccounts and getSignaturesForAddress counted differently?
• Is there a separate limit for WebSocket subscriptions?
• What happens on breach: hard rejection, temporary throttle, or overage billing?

When a provider only publishes one number, assume the other dimensions are enforced somewhere and ask support directly. For a broader framework, see how to choose an RPC provider.

Testing limits safely before you commit

You can measure real behavior without abusing an endpoint. The goal is to find the point where your workload degrades, not to hammer the provider.

Start with a small, scripted probe against your candidate endpoint. Use your own key, keep concurrency low, and increase gradually.

# Probe request rate and observe throttling behavior
for i in $(seq 1 20); do
  curl -s -o /dev/null -w "%{http_code} %{time_total}s\n" \
    -X POST https://solana.api.onfinality.io/public \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","id":1,"method":"getLatestBlockhash","params":[{"commitment":"confirmed"}]}'
done

Watch for three signals: rising latency, HTTP 429 responses, and JSON-RPC error codes. If latency climbs steadily before you hit a 429, the endpoint is saturating earlier than its published rate suggests.

For WebSocket capacity, open a small number of subscriptions and watch for dropped streams:

import WebSocket from "ws";

const ws = new WebSocket("wss://solana.api.onfinality.io/public-ws");

ws.on("open", () => {
  ws.send(JSON.stringify({
    jsonrpc: "2.0",
    id: 1,
    method: "slotSubscribe",
    params: []
  }));
});

ws.on("message", (data) => {
  const msg = JSON.parse(data.toString());
  console.log("slot notification:", msg.params?.result?.slot ?? msg);
});

ws.on("close", (code) => console.log("closed:", code));

Run the same probe against each candidate and record the results in a table. Consistency across runs matters more than any single peak number.

Provider evaluation matrix for Solana rate comparisons

Use a matrix like this when you shortlist providers. Fill it in with your own measurements rather than marketing copy.

OnFinality appears first here because it is the option this site operates: it provides a Solana RPC API with HTTP and WebSocket transport, plus dedicated node infrastructure for teams that outgrow shared pools. Compare it against the same columns you use for any other provider.

Shared RPC API versus dedicated Solana node

The rate question often resolves into a build-versus-buy decision about capacity.

A shared RPC API is the right default when your traffic is moderate, bursty, or hard to predict. You get an endpoint, you pay for usage or a plan tier, and the provider manages the node fleet. The tradeoff is that you share capacity, so your effective ceiling depends on how the provider isolates tenants.

A dedicated node is the right move when you need predictable throughput, low latency from a specific region, heavy archive or trace-style reads, or isolation from other tenants' traffic. The tradeoff is cost and operational responsibility, though a managed dedicated node keeps the node itself off your plate.

A simple rule: if your 429 rate is rising while your request volume is stable, you have outgrown the shared tier. If your latency is fine but your bill is unpredictable, revisit your plan shape instead. See dedicated nodes for the managed option.

Common pitfalls when comparing Solana RPC rates

• Comparing RPS across different metering models. A per-compute provider and a per-call provider are not directly comparable.
• Ignoring commitment levels. processed, confirmed, and finalized have different costs and latency; test with the commitment you ship.
• Benchmarking from the wrong region. Network distance dominates latency; test from where your app runs.
• Overlooking WebSocket churn. Reconnect storms can look like a rate problem when the real issue is subscription handling.
• Treating a free public endpoint as a production tier. Public endpoints are useful for tests and prototypes, not for sustained load.

Monitoring the rate you actually get

Once you pick a provider, instrument the endpoint so you can see degradation before users do. Track request latency percentiles, 429 counts, JSON-RPC error codes, WebSocket reconnect frequency, and per-method call volume. A lightweight probe on a schedule gives you a baseline you can compare against after any provider change.

async function probe(endpoint) {
  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: "getHealth",
      params: []
    })
  });
  return { status: res.status, ms: Date.now() - start };
}

setInterval(async () => {
  console.log(await probe("https://solana.api.onfinality.io/public"));
}, 30000);

Keep the probe cheap and consistent. The value is in the trend line, not any single sample.

Key Takeaways

• "Rate" on Solana is multi-dimensional: request rate, compute units, payload caps, concurrency, and burst behavior all matter.
• A single published RPS number is not enough to compare providers; ask how heavy methods and WebSockets are metered.
• Test candidate endpoints with small, gradual probes and record latency, 429s, and error codes.
• Shared RPC APIs fit bursty, moderate traffic; dedicated nodes fit sustained, latency-sensitive, or archive-heavy workloads.
• Instrument your chosen endpoint so you can detect throttling and latency drift early.
• Review RPC pricing and supported RPC networks to match a plan to your workload.

FAQ

Can I compare Solana RPC providers using just their published RPS? No. RPS is one dimension. Compute-unit metering, payload caps, WebSocket limits, and burst handling often matter more for real workloads.

Why do two providers with the same RPS perform differently? Because they meter different things and isolate tenants differently. A provider that charges per compute unit or shares capacity across tenants can behave very differently under load.

How do I know when to move from a shared endpoint to a dedicated node? When you see rising 429s or latency at stable request volume, when you need archive or heavy historical reads, or when you need predictable latency from a specific region.

Does OnFinality offer Solana RPC and dedicated nodes? Yes. OnFinality provides a Solana RPC API with HTTP and WebSocket transport, and dedicated node infrastructure for teams that need more control. See the Solana network page for details.

What should I monitor after switching providers? Latency percentiles, 429 counts, JSON-RPC error codes, WebSocket reconnect frequency, and per-method call volume. Compare these against your pre-switch baseline.