Quick recommendation: match rate limits to your workload
Before comparing providers, decide what your application actually needs. A lightweight NFT ticker can run on a shared RPC with modest request caps. A high-frequency trading bot or a Solana indexer that replays historical data will exhaust shared limits quickly and likely needs a dedicated node or a plan with compute-unit-based metering.
Ask three questions:
-
What is your request pattern? Bursty calls to
getLatestBlockhashorsendTransactionneed headroom above the average RPS. - Do you use WebSocket subscriptions? Many providers count each subscription separately and cap the number of concurrent connections.
-
Do you need historical data? Methods like
getSignaturesForAddressandgetTransactionare expensive; providers may meter them more heavily.
If you expect sustained load or need predictable performance, evaluate dedicated node options early. OnFinality offers dedicated Solana nodes with isolated capacity, and its RPC pricing page lists shared and dedicated plans. For a broader view of provider selection criteria, see how to choose an RPC provider.
Why rate limiting matters on Solana
Solana is designed for high throughput, but that throughput depends on the RPC endpoint you use. A single shared endpoint can be overwhelmed by a few heavy consumers, degrading latency for everyone. Rate limits protect the provider's infrastructure and ensure fair use, but they also directly affect your application's reliability.
Unlike Ethereum, where a simple request-per-second cap is common, Solana RPC providers often use more granular metering. Some count every JSON-RPC call equally, while others assign a cost to each method based on its computational load. This means a plan that allows 100 RPS might still throttle you if you send many getTransaction requests, which are far more expensive than getSlot.
Rate limiting models used by Solana RPC providers
Providers generally fall into three categories:
1. Requests-per-second (RPS) caps
The simplest model: you are allowed a fixed number of requests per second, often per IP address. Free tiers might allow 10-50 RPS, while paid tiers scale to hundreds or thousands. This model is easy to understand but can be unfair for methods with very different costs.
2. Compute-unit or credit-based metering
Some providers assign a cost to each RPC method, similar to Solana's own compute limits. A simple getHealth call might cost 1 credit, while getTransaction with a large response could cost 10 or more. Your plan includes a monthly credit allowance, and you are throttled when you exhaust it. This model aligns pricing with actual server load but requires you to estimate your usage more carefully.
3. Concurrent connection limits for WebSocket
WebSocket subscriptions are essential for real-time updates, but they hold a persistent connection. Providers often limit the number of concurrent WebSocket connections, and some also cap the number of subscriptions per connection. If you need to monitor many accounts, this limit can become a bottleneck.
Comparing top Solana RPC providers
The table below summarizes the rate limiting approaches of leading providers. Always check the provider's current documentation, as plans change frequently.
| Provider | Rate limit model | Free tier | WebSocket limits | Dedicated option |
|---|---|---|---|---|
| OnFinality | RPS-based with tiered plans | Yes | Yes, per plan | Yes, isolated node |
| Provider A | RPS + compute units | Yes | Yes, lower caps | Yes |
| Provider B | Credit-based | Yes | Yes, per subscription | Yes |
| Provider C | RPS only | No | No | No |
OnFinality offers shared RPC endpoints with clear RPS limits per plan, plus dedicated nodes that remove shared throttling entirely. Its Solana network page lists the public endpoint and WebSocket URL for testing.
Provider A uses a hybrid model: a base RPS cap plus compute-unit metering for expensive methods. This can be cost-effective for light users but may surprise you if you rely on getSignaturesForAddress.
Provider B is popular for its credit system, which gives you a monthly allowance. It is predictable for steady workloads but can be hard to tune for bursty traffic.
Provider C offers only a simple RPS cap and lacks WebSocket support, making it unsuitable for real-time applications.
How to evaluate rate limits for your use case
When comparing plans, look beyond the headline RPS number. Consider:
-
Method cost: Does the provider meter
getTransactionorgetSignaturesForAddressmore heavily? If so, factor that into your capacity planning. - Burst allowance: Some providers allow short bursts above the average RPS, while others hard-throttle at the limit. If your app has spikes, a burst allowance is valuable.
- IP-based vs. key-based limits: If you run multiple backend servers, IP-based limits can be problematic. Key-based limits tied to your API key are easier to manage.
- WebSocket subscription caps: Count how many subscriptions you need concurrently and verify the provider supports that number.
- Archive data access: If you need historical data, check whether the provider offers archive nodes and whether those requests count against the same limits.
Testing rate limits before you commit
You can measure a provider's rate limiting behavior with a simple script. The following example sends a burst of getSlot requests and reports how many succeed before hitting the limit.
for i in $(seq 1 200); do
curl -s -o /dev/null -w "%{http_code}\n" \
-X POST https://solana.api.onfinality.io/public \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","id":1,"method":"getSlot"}'
done | sort | uniq -c
If you see HTTP 429 responses, you have hit the rate limit. The exact threshold will depend on the provider and plan. For a production test, use your API key and a realistic mix of methods.
WebSocket rate limits and how to handle them
WebSocket connections are often limited separately from HTTP requests. A common limit is 10-50 concurrent connections per API key. If you need more, you might need a dedicated node.
To reduce the number of connections, you can use a single subscription with filters instead of subscribing to each account individually. For example, use programSubscribe to monitor all accounts of a program rather than subscribing to each address.
Here is a Node.js snippet that opens a WebSocket connection to the OnFinality public endpoint and subscribes to slot updates:
const WebSocket = require('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) => {
console.log(data.toString());
});
Remember that each subscription consumes a slot in your connection limit. Monitor your usage to avoid unexpected disconnects.
When to choose a dedicated Solana node
Shared RPC endpoints are cost-effective for development and low-traffic applications, but they have inherent limits. If you experience any of the following, consider a dedicated node:
- You regularly hit HTTP 429 or WebSocket disconnects.
- Your application requires consistent low latency for trading or gaming.
- You need to run heavy analytics or index large amounts of historical data.
- You want to avoid noisy neighbors who might degrade shared endpoint performance.
OnFinality's dedicated node service provides a Solana node with dedicated resources, giving you full control over rate limits and performance. You can also use it to access archive data or run custom configurations.
Common rate limit errors and how to debug them
When you exceed a rate limit, you will typically see one of these responses:
- HTTP 429 Too Many Requests: The provider is throttling your requests. Check your current usage against your plan limits.
-
JSON-RPC error -32005: This is a Solana-specific error indicating you have exceeded the node's rate limit. It often includes a
retryAfterfield. - WebSocket close code 1008: The server is closing the connection due to policy violation, often because you exceeded the subscription limit.
To debug, add logging to your RPC client to capture response headers and error codes. Many providers include headers like x-ratelimit-remaining that help you track your usage.
Key Takeaways
- Rate limiting models vary: RPS caps, compute-unit metering, and WebSocket connection limits are the most common.
- Match the provider's model to your workload: bursty apps need headroom, heavy analytics need archive access, and real-time apps need WebSocket capacity.
- Always test rate limits with a realistic request mix before committing to a plan.
- Dedicated nodes eliminate shared throttling and provide predictable performance for demanding applications.
- Check the latest documentation from each provider, as limits and pricing change frequently.
Frequently Asked Questions
What is a typical free tier rate limit for Solana RPC providers?
Free tiers often allow between 10 and 50 requests per second, with lower WebSocket connection limits. Some providers also cap the number of daily requests. These limits are sufficient for development and light testing but not for production traffic.
How do I know if I need a dedicated Solana node?
If you consistently hit rate limits, need low latency for time-sensitive applications, or require archive data access, a dedicated node is worth the investment. It provides isolated resources and removes the variability of shared endpoints.
Can I use the same API key across multiple servers?
Most providers allow this, but rate limits may be applied per IP address or per key. If you have multiple servers, check whether the provider aggregates usage or applies limits per IP. Key-based limits are easier to manage in a distributed setup.
Do WebSocket subscriptions count against the same rate limit as HTTP requests?
Usually not. Providers typically have separate limits for WebSocket connections and subscriptions. You should monitor both to avoid unexpected throttling.
How can I monitor my RPC usage?
Many providers offer a dashboard where you can view request counts, error rates, and current limits. You can also add client-side logging to track response codes and headers. For a comprehensive approach, consider using a monitoring service that tracks RPC health and latency.
For more details on Solana RPC endpoints and plans, visit the Solana network page and the RPC pricing page.
Related resources
Originally published at OnFinality.
Top comments (0)