Solana RPC Rate Limits by Provider

Disclosure: This page compares publicly available information about RPC providers. Data was gathered from providers’ public documentation and pricing pages as of 2026-10-19. Rates and limits change — verify current values on each provider’s website.

Every Solana RPC provider enforces rate limits. Understanding how limits work helps you choose the right plan and avoid disruptions from 429 errors.

How rate limits work

Providers use different limiting models:

Requests per second (RPS)

A fixed number of requests per second, regardless of method complexity. Simple and predictable, but a getSlot costs the same as a getProgramAccounts.

Compute units per second (CUPS)

Each method has a cost weight. Light methods (getSlot: 1 CU) are cheap; heavy methods (getProgramAccounts: 100-500 CU) are expensive. You get a budget of CUs per second.

Monthly request caps

A total number of requests per billing period. Once exhausted, requests are throttled or blocked until the next period.

Public RPC limits

The Solana Foundation’s public endpoint (api.mainnet-beta.solana.com) has the strictest limits:

The public endpoint is for development only. Do not use it in production.

What to check in a provider’s rate limit policy

1. Per-method limits. Some providers apply different limits to heavy methods like getProgramAccounts, getSignaturesForAddress, and getBlock. These may have separate, lower limits than standard methods.

2. Burst vs sustained. A provider may allow 200 req/s burst but only 100 req/s sustained. Burst limits refill over time (token bucket model).

3. WebSocket limits. WebSocket connections and subscriptions often have separate limits from HTTP. Check: max connections, max subscriptions per connection, and whether WebSocket traffic counts toward HTTP limits.

4. Response size limits. Large responses from getBlock with full transaction data or unfiltered getProgramAccounts may be truncated or rejected.

5. Overage behavior. When you exceed limits: do requests get queued (added latency), return 429 errors, or is there a soft limit with overage charges?

Handling 429 errors

When you receive a 429 (Too Many Requests) error:

async function rpcWithRetry(rpc: any, method: string, params: any[]) {
  const MAX_RETRIES = 3;
  let delay = 500;

  for (let attempt = 0; attempt < MAX_RETRIES; attempt++) {
    try {
      return await rpc[method](...params).send();
    } catch (error: any) {
      if (error?.message?.includes("429") && attempt < MAX_RETRIES - 1) {
        await new Promise((r) => setTimeout(r, delay));
        delay *= 2; // Exponential backoff
        continue;
      }
      throw error;
    }
  }
}

Best practices for staying under limits

FAQ

Why am I getting 429 errors below my plan’s stated limit? Possible reasons: per-method sublimits for heavy methods, burst limit exceeded, shared infrastructure under load, or your IP is shared with other users (common in cloud environments).

Do WebSocket messages count toward rate limits? It varies. Some providers meter WebSocket subscription creation separately from incoming data messages. Others include all traffic in one budget. Check your provider’s documentation.

Can I increase my rate limits without upgrading? Some providers offer rate limit increases as add-ons. Others require a plan upgrade. Contact your provider’s support for custom limits.

Are rate limits per IP or per API key? Most providers use API key-based limits. This means all your servers sharing one API key share one limit. Use separate keys for separate services where possible.

Updated: 2026-10-19