Which Solana RPC providers have the most competitive rate limiting?

Quick recommendation: match rate limits to your traffic pattern

Rate limiting is not a one-size-fits-all metric. A provider that looks generous on requests per second (RPS) may still throttle your app if you burst past a per-second cap or open too many WebSocket connections. Before comparing providers, map your workload:

• Read-heavy apps (indexers, dashboards) need high RPS and access to getProgramAccounts or getSignaturesForAddress without aggressive caps.
• Write-heavy apps (trading bots, NFT minters) need consistent throughput for sendTransaction and low-latency confirmation polling.
• Real-time apps (order books, wallet activity) need WebSocket subscriptions with enough concurrent connections and message throughput.

For most production Solana apps, a managed provider with transparent rate limits and a path to dedicated infrastructure is the safest choice. OnFinality offers both shared and dedicated Solana RPC options, with rate limits that scale to your needs. See RPC pricing and the Solana network page for current details.

How Solana RPC rate limits are typically structured

Solana RPC providers usually enforce limits in three dimensions:

• Requests per second (RPS): the maximum number of JSON-RPC calls per second. This is the most common limit and is often tiered by plan.
• Daily/monthly request volume: a cap on total requests over a billing period. Useful for estimating cost, but less relevant for real-time behavior.
• WebSocket connections and message rate: the number of concurrent WebSocket connections and the frequency of messages you can receive. This is critical for apps that subscribe to account or program updates.

Some providers also impose method-specific limits—for example, a lower RPS for expensive calls like getProgramAccounts or getSignaturesForAddress. These can be more restrictive than the overall RPS cap, so always read the fine print.

Burst vs. sustained limits

A provider may allow short bursts above the stated RPS (e.g., 10 RPS sustained with 20 RPS bursts for 5 seconds). Burst allowances are useful for handling spikes, but they are not guaranteed. If your app regularly exceeds the sustained limit, you will see 429 errors or dropped requests.

What to compare across Solana RPC providers

When evaluating providers, focus on the following criteria. Use the table below as a starting point—then verify current details on each provider's site.

Note: The table is illustrative. Always check the provider's current documentation for exact numbers.

Key questions to ask

• What is the sustained RPS on the plan I need? Not just the burst rate.
• Are there method-specific limits? For example, getProgramAccounts may be capped lower than general calls.
• How many WebSocket connections can I open? Some providers limit to 10 or 20; others allow hundreds.
• What happens when I exceed the limit? Do you get 429 errors, or does the provider queue requests?
• Can I upgrade to a dedicated node if I outgrow shared limits? This is crucial for scaling.

How to test rate limits before committing

You can write a simple script to probe a provider's rate limits. Use a loop that sends requests and logs HTTP status codes. Here's a Node.js example using fetch:

const endpoint = 'https://solana.api.onfinality.io/public';
const body = {
  jsonrpc: '2.0',
  id: 1,
  method: 'getHealth',
  params: []
};

async function testRateLimit() {
  let success = 0;
  let rateLimited = 0;
  for (let i = 0; i < 100; i++) {
    try {
      const res = await fetch(endpoint, {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify(body)
      });
      if (res.status === 429) {
        rateLimited++;
      } else {
        success++;
      }
    } catch (e) {
      console.error('Error:', e);
    }
    await new Promise(r => setTimeout(r, 100)); // 10 RPS
  }
  console.log(`Success: ${success}, Rate limited: ${rateLimited}`);
}

testRateLimit();

Run this against different providers to see how they behave under sustained load. Also test WebSocket connections by opening multiple subscriptions and monitoring for disconnects.

Common pitfalls when comparing rate limits

• Ignoring method-specific caps: A provider may advertise 50 RPS but only allow 5 RPS for getProgramAccounts. This can break indexers.
• Overlooking WebSocket limits: If your app needs 100 concurrent subscriptions, a provider with a 20-connection limit will fail.
• Assuming free tier is enough for production: Free tiers are for testing, not production. They often have low RPS and no SLA.
• Not checking burst behavior: Some providers allow short bursts, but sustained load may still trigger throttling.
• Forgetting about archive data: If you need historical state, ensure the provider offers archive nodes with adequate rate limits.

When to choose a dedicated Solana node

Shared RPC plans are cost-effective for moderate traffic, but they have limits that can become a bottleneck. Consider a dedicated node when:

• Your app consistently hits the RPS cap on a shared plan.
• You need predictable performance for high-frequency trading or large-scale indexing.
• You require custom rate limits or want to avoid noisy neighbors.
• You need access to archive data or specialized methods without restrictions.

OnFinality provides dedicated Solana nodes that give you full control over rate limits and performance. Learn more on the dedicated node page.

How to plan for rate limit headroom

Even with a generous plan, you should design your app to handle rate limits gracefully:

• Implement retry with exponential backoff for 429 responses.
• Cache responses for frequently accessed data to reduce RPS.
• Use WebSocket subscriptions instead of polling when possible, but watch connection limits.
• Monitor your usage to detect when you're approaching limits.

Here's a simple retry pattern in JavaScript:

async function rpcCall(method, params, retries = 3) {
  const endpoint = 'https://solana.api.onfinality.io/public';
  for (let i = 0; i < retries; i++) {
    const res = await fetch(endpoint, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ jsonrpc: '2.0', id: 1, method, params })
    });
    if (res.status === 429) {
      await new Promise(r => setTimeout(r, 1000 * Math.pow(2, i)));
      continue;
    }
    return res.json();
  }
  throw new Error('Rate limited after retries');
}

Key Takeaways

• Rate limits on Solana RPC are multi-dimensional: RPS, daily volume, and WebSocket concurrency.
• Method-specific caps can be more restrictive than the overall RPS.
• Test providers with your actual workload before committing.
• Shared plans are fine for moderate traffic; dedicated nodes offer predictable performance.
• Always design for rate limit errors with retries and caching.

Frequently Asked Questions

What is a typical free tier RPS for Solana RPC providers?

Free tiers often range from 2 to 10 RPS, but some providers may offer higher limits for testing. Always check the current terms.

Can I get unlimited RPS on a shared plan?

No provider offers truly unlimited RPS on shared plans. Dedicated nodes are the way to get higher, predictable limits.

How do WebSocket limits affect my app?

If your app relies on real-time updates, you need enough concurrent WebSocket connections. Exceeding the limit will cause disconnects or errors.

What should I do if I hit rate limits frequently?

First, optimize your app with caching and batching. If you still hit limits, consider upgrading to a higher plan or a dedicated node.

Does OnFinality offer dedicated Solana nodes?

Yes, OnFinality provides dedicated Solana nodes. Visit the dedicated node page for details.