How do usage tiers compare across popular Solana RPC providers?

Solana RPC providers rarely publish a single price. They publish tiers, and those tiers differ in ways that matter more than the headline number: request allowances, compute-unit weighting, WebSocket support, archive access, and whether capacity is shared or reserved. If you are comparing providers, the useful question is not "which tier is cheapest" but "which tier matches my request mix and failure tolerance."

Quick recommendation: match the tier to your workload shape

Before reading any pricing page, classify your workload. Solana traffic is not uniform, and the same tier can be comfortable for one app and unusable for another.

If your app can tolerate occasional failed calls and you are still validating product-market fit, a shared tier is usually enough. If a failed call means a missed trade, a stalled indexer, or a broken user flow, reserve capacity. OnFinality offers both shared RPC API access and dedicated nodes for Solana, so you can start shared and move to reserved capacity without changing your integration pattern.

What "usage tier" actually measures on Solana

On EVM chains, tiers are often described in requests per second. Solana is different because a single JSON-RPC call can be cheap or expensive depending on the method and the response size.

• getHealth and getSlot are lightweight and often used for liveness checks.
• getAccountInfo and getMultipleAccounts scale with the number of accounts and the size of the data returned.
• getProgramAccounts can be extremely heavy, especially with filters, and many providers weight or restrict it.
• getSignaturesForAddress and getTransaction scale with history depth and response size.
• sendTransaction is usually weighted by transaction size and priority fee context.

Because of this, providers increasingly describe tiers in compute units or weighted requests rather than raw call counts. When you compare tiers, ask how each provider weights the methods you actually call. A tier that looks generous at 1,000 requests per second may behave very differently once getProgramAccounts enters the mix.

How the three common tier families differ

Public and free shared endpoints

Public endpoints are best understood as a convenience, not a capacity plan. They are useful for wallets, tutorials, quick scripts, and health checks. They typically share capacity across all callers, may throttle aggressively under load, and rarely come with any commitment about availability. Some public endpoints support WebSocket; many do not, or support it with strict connection limits.

OnFinality publishes a public Solana endpoint at https://solana.api.onfinality.io/public with a matching WebSocket endpoint at wss://solana.api.onfinality.io/public-ws. It is a reasonable starting point for development and testing, but production apps should plan for a managed or dedicated tier.

Shared managed tiers

Shared managed tiers give you a private API key, a documented allowance, and access to a pool of nodes. You share the underlying infrastructure with other customers, but you get better isolation than a public endpoint, plus support and monitoring.

What to check in this tier family:

• How the allowance is expressed (requests, compute units, or a mix).
• What happens when you exceed it: hard failure, throttling, or overage billing.
• Whether WebSocket subscriptions count against the same allowance.
• Whether archive data is included or sold separately.
• Whether you can burst during traffic spikes without pre-approval.

Dedicated nodes and reserved capacity

Dedicated nodes give your workload its own node or node cluster. You get a private endpoint, predictable throughput, and the ability to tune the node for your access patterns. This is the tier that trading systems, indexers, and high-traffic consumer apps tend to graduate into.

Dedicated capacity is not automatically faster for every workload. It is most valuable when your traffic is heavy, bursty, or sensitive to noisy-neighbor effects. If your app makes a few thousand calls per day, a dedicated node is usually over-provisioned.

Provider evaluation matrix

The table below compares tier families rather than naming every vendor, because the same tier label can mean different things across providers. Use the columns as questions to ask each provider you evaluate.

OnFinality appears first here because it is the option this site documents in detail, not because other providers are unsuitable. Compare every row against your own workload before deciding.

Testing a tier with real Solana calls

Do not size a tier from a pricing page alone. Run a short load test against your candidate endpoint using the methods your app actually calls. Start with a basic connectivity and slot check:

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

Then test a heavier read that resembles your production pattern, such as fetching a program account with filters:

curl -s https://solana.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"getProgramAccounts","params":["YourProgramIdHere",{"encoding":"base64","filters":[{"dataSize":165}]}]}'

For WebSocket workloads, verify that subscriptions stay stable under sustained load. A simple Node.js probe looks like this:

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"
  }));
});

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

ws.on("close", () => console.log("socket closed"));
ws.on("error", (err) => console.error("socket error", err.message));

Run these probes against each candidate tier for at least a few hours, ideally across a full traffic cycle. Track error rates, p95 latency, and how the endpoint behaves when you push past your expected peak.

Signals that you have outgrown your current tier

Tier upgrades are usually triggered by symptoms, not by a calendar. Watch for these signals:

• Rising 429 responses or throttling messages during peak hours.
• WebSocket disconnects that correlate with traffic spikes.
• Latency variance that widens when other tenants are busy.
• Failed getProgramAccounts or getSignaturesForAddress calls under load.
• Growing need for archive data that your current tier does not include.

If two or more of these appear together, the tier is the constraint, not your application code. At that point, compare the cost of a higher shared tier against a dedicated node and decide based on how much variability you can absorb.

Cost and risk tradeoffs to weigh

Cheaper tiers shift risk onto your application. That is not automatically bad, but it should be a conscious decision.

• A public endpoint saves money but moves availability risk to you.
• A shared managed tier balances cost and reliability, but method weighting can make costs hard to predict.
• A dedicated node costs more but makes throughput and latency more predictable.
• Self-hosting can be the cheapest at very high, very steady load, but adds upgrade, monitoring, and on-call work.

For most teams, the practical path is to start on a shared tier, instrument your traffic, and move to dedicated capacity when the signals above appear. OnFinality's RPC pricing page describes how tiers are structured, and the supported networks page lists where Solana and other chains are available.

Migration checkpoints when you change tiers

Changing tiers should not require rewriting your app. Keep these checkpoints in mind:

1. Confirm the new endpoint supports the same commitment levels and methods you rely on.
2. Verify WebSocket behavior if you use subscriptions, including reconnect logic.
3. Re-run your load test against the new endpoint before cutting over production traffic.
4. Keep the old endpoint configured as a fallback until the new one has run through a full traffic cycle.
5. Update monitoring dashboards so you can compare error rates and latency before and after.

If you use a wallet or client library, the endpoint change is usually a single configuration value. For example, in a Solana web3.js client:

import { Connection } from "@solana/web3.js";

const connection = new Connection(
  "https://solana.api.onfinality.io/public",
  "confirmed"
);

Key Takeaways

• Solana RPC usage tiers differ mainly in capacity model, method weighting, WebSocket support, and archive access, not just price.
• Public endpoints are fine for development but are not a capacity plan for production traffic.
• Shared managed tiers fit steady read workloads; dedicated nodes fit bursty, latency-sensitive, or high-volume workloads.
• Size your tier with real JSON-RPC calls, including the heaviest methods your app uses, before you commit.
• Watch for throttling, WebSocket disconnects, and latency variance as signals that you have outgrown your current tier.
• OnFinality offers shared RPC API access and dedicated nodes for Solana, so you can move between tiers without changing your integration pattern.

Frequently Asked Questions

Do all Solana RPC providers count requests the same way?

No. Some count raw requests, some count compute units, and some weight heavy methods like getProgramAccounts more than light ones like getSlot. Always ask how your specific methods are weighted.

Is a dedicated Solana node always faster than a shared tier?

Not always. Dedicated capacity is most valuable when your traffic is heavy, bursty, or sensitive to noisy-neighbor effects. For light workloads, a shared tier can be sufficient.

Can I use a public Solana RPC endpoint in production?

You can, but public endpoints are typically shared and best-effort. Production apps usually move to a managed or dedicated tier once traffic grows or reliability requirements increase.

How do I know when to upgrade my Solana RPC tier?

Look for throttling responses, WebSocket disconnects during peak traffic, widening latency variance, and failed heavy calls. Two or more of these together usually indicate the tier is the constraint.

Does OnFinality support WebSocket subscriptions for Solana?

Yes. OnFinality's Solana configuration includes both an HTTP endpoint and a WebSocket endpoint. Check the Solana network page for current endpoint details.