Which Solana RPC providers offer the best rate limiting and usage tiers?

Solana's high-throughput design means RPC providers must balance request volume against node resources. Unlike Ethereum-style chains where block times are predictable, Solana produces blocks roughly every 400ms, and a single getProgramAccounts call can return megabytes of data. That makes rate limiting and usage tiers a first-class concern when you evaluate providers.

This article breaks down how Solana RPC rate limits are typically structured, what to compare across tiers, and how to match a provider to your workload. It is written for developers and infrastructure buyers who need predictable throughput without guessing at hidden caps.

Quick recommendation: match the tier to your request shape

Before comparing provider names, classify your workload. Solana rate limits are usually expressed as requests per second (RPS), requests per 10 seconds, or compute units per second. The right tier depends less on brand and more on your request pattern.

If your app falls into the first or last row, a shared endpoint such as OnFinality's Solana RPC API is usually sufficient. If you are in the middle rows, plan for a dedicated node or a paid tier with documented limits.

How Solana RPC rate limiting actually works

Providers rarely publish a single number. Instead, they combine several mechanisms:

• Requests per second (RPS): a hard cap on how many HTTP calls you can make per second.
• Compute units (CU): a weighted budget where expensive methods cost more. getProgramAccounts might cost 100 CU while getBalance costs 1 CU.
• Concurrency limits: how many in-flight requests your API key can have at once.
• WebSocket subscription caps: how many accounts or programs you can subscribe to simultaneously.
• Burst allowances: short-term spikes above the steady-state limit, often with a cooldown.

When you exceed a limit, the provider typically returns HTTP 429 with a JSON-RPC error body. Some providers silently drop WebSocket messages instead, which is harder to debug.

A typical 429 response looks like this:

{
  "jsonrpc": "2.0",
  "error": {
    "code": -32429,
    "message": "Too many requests"
  },
  "id": 1
}

If you see this during normal operation, your tier is undersized for your workload.

What to compare across usage tiers

Not all "unlimited" or "high-throughput" tiers mean the same thing. When you read a pricing page, extract these details:

1. Limit unit: Is the cap in RPS, CU, or both? A 100 RPS tier with a 10,000 CU/s budget behaves very differently from a 100 RPS tier with no CU weighting.
2. Method restrictions: Some tiers exclude getProgramAccounts, getSignaturesForAddress, or archive queries. Check the method allowlist.
3. WebSocket support: If you rely on accountSubscribe or logsSubscribe, confirm the tier includes WebSocket and how many subscriptions are allowed.
4. Burst behavior: Does the provider allow short spikes, or is the limit enforced per second with no buffer?
5. Overage handling: Does the provider throttle, bill overages, or queue requests? Queuing adds latency; throttling causes errors.
6. Key rotation and team access: For teams, check whether you can issue multiple API keys with separate limits.

A useful comparison table for provider evaluation:

OnFinality's RPC pricing page lists current tier structure, and dedicated nodes are available when shared limits are not enough.

Provider-by-provider notes on rate limiting and tiers

This is not a ranking. It is a summary of how different provider models approach rate limiting, so you can ask the right questions.

OnFinality offers a shared Solana RPC API with documented usage tiers and a path to dedicated Solana nodes. The shared endpoint is suitable for development and moderate production traffic, while dedicated nodes remove shared-pool rate limits and give you a private endpoint. OnFinality also supports HTTP and WebSocket transports on Solana, which matters if you use subscriptions.

Public/free endpoints (including Solana's own public RPC) typically have aggressive rate limits, no SLA, and no WebSocket guarantees. They are fine for testing but not for production traffic.

Managed RPC providers with credit-based pricing often meter by compute units rather than RPS. This can be cheaper for light workloads but harder to predict for indexers that call expensive methods.

Dedicated node providers sell you a private node, which effectively removes shared rate limits but shifts responsibility for monitoring and scaling to you or your provider's managed layer.

Exchange or wallet RPC endpoints are usually not available for third-party apps, so they rarely appear in provider comparisons.

When comparing, ask each provider for their rate limit documentation in writing. If a provider cannot state the limit unit and overage behavior, treat that as a risk.

Testing rate limits before you commit

You can measure your effective rate limit with a simple load test. Start with a low concurrency and increase until you see 429s or rising latency.

# Simple RPS probe against a Solana RPC endpoint
for i in $(seq 1 50); do
  curl -s -o /dev/null -w "%{http_code} %{time_total}\n" \
    -X POST https://solana.api.onfinality.io/public \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","id":1,"method":"getSlot","params":[]}'
done

Run this against your candidate endpoint and watch for HTTP 429 responses or latency spikes. For WebSocket, test subscription limits separately:

// WebSocket subscription probe
const ws = new WebSocket("wss://solana.api.onfinality.io/public-ws");
ws.onopen = () => {
  ws.send(JSON.stringify({
    jsonrpc: "2.0",
    id: 1,
    method: "slotSubscribe"
  }));
};
ws.onmessage = (event) => console.log(event.data);

If you need a private endpoint, replace the URL with your dedicated node URL from the provider dashboard.

When to move from shared to dedicated

Shared tiers are cost-effective until contention or limits start affecting your app. Consider a dedicated Solana node when:

• You consistently hit 429s during peak traffic.
• You need archive data or getProgramAccounts at high volume.
• You require predictable latency for trading or liquidation logic.
• You want isolated WebSocket subscriptions without shared-pool noise.
• You need to run custom plugins or specific Solana client versions.

OnFinality's dedicated node option provides a private Solana endpoint with configurable resources. For teams that want managed infrastructure without operating validators, this is often the middle ground between shared RPC and self-hosting.

Operational checklist for Solana RPC tiers

Once you pick a tier, put these practices in place:

• Instrument 429s: log every rate-limit response with the method name and timestamp.
• Cache aggressively: getLatestBlockhash, getEpochInfo, and token metadata change slowly; cache them.
• Batch requests: JSON-RPC batch calls reduce HTTP overhead but still count toward CU limits.
• Use WebSocket for subscriptions: polling getAccountInfo in a loop is the fastest way to hit limits.
• Set client-side timeouts and retries: exponential backoff on 429 is safer than immediate retry.
• Monitor CU per method: if your provider exposes metrics, track which methods consume the most budget.
• Plan for failover: configure a secondary endpoint in case your primary is throttled or degraded.

For a broader provider selection framework, see How to choose an RPC provider.

Key Takeaways

• Solana RPC rate limits are usually a mix of RPS, compute units, concurrency, and WebSocket subscription caps.
• The best tier depends on your request shape, not just your monthly volume.
• Shared endpoints like OnFinality's Solana RPC API fit light dApps and development; dedicated nodes fit high-throughput or latency-sensitive workloads.
• Always ask providers for written rate limit documentation, including overage behavior.
• Test limits with a load probe before committing to a tier.
• Cache, batch, and use WebSocket subscriptions to stay within limits.

Frequently Asked Questions

Do all Solana RPC providers use the same rate limit units? No. Some use requests per second, others use compute units, and some combine both. Always confirm the unit before comparing tiers.

Is a free Solana RPC endpoint enough for production? Free and public endpoints usually have aggressive limits and no SLA. They are fine for testing but risky for production traffic.

How do I know if I need a dedicated Solana node? If you consistently hit 429s, need archive or getProgramAccounts at volume, or require predictable latency, a dedicated node is the next step.

Can I use WebSocket subscriptions on a shared tier? Many providers support WebSocket on shared tiers but cap the number of subscriptions. Check the limit before building real-time features.

What happens when I exceed my usage tier? Behavior varies: some providers throttle with 429s, some queue requests, and some bill overages. Confirm this before you commit.

Does OnFinality offer Solana WebSocket endpoints? Yes, OnFinality supports HTTP and WebSocket transports for Solana. See the Solana network page for endpoint details.

For current tier options, visit RPC pricing, and browse supported RPC networks to see where Solana fits in your multi-chain setup.