Solana applications depend on RPC providers for everything from reading account state to submitting transactions. When you compare providers, rate limits and usage tiers often matter more than raw latency or uptime. A plan that looks generous on paper can still throttle your workload if the limit is measured in requests per second rather than compute units, or if heavy methods like getProgramAccounts count against a separate quota.
This article walks through the rate-limiting models you will encounter, the usage tiers providers publish, and the questions to ask before you commit. The goal is to help you map your traffic profile to a provider plan instead of guessing.
Decision guide: match your workload to a provider tier
Before comparing price lists, define your workload. Solana RPC traffic is not uniform. A simple NFT minting site, a DEX aggregator, and a validator monitoring bot each place very different demands on an endpoint.
| Workload | Typical request pattern | What matters most |
|---|---|---|
| Light dApp (read balances, occasional transactions) | Low QPS, bursty | Free tier or low-cost shared plan |
| Trading bot or market maker | High QPS, low latency, WebSocket subscriptions | Dedicated node, high rate limit, low latency |
| Data indexer or analytics | Heavy getProgramAccounts, getSignaturesForAddress
|
Compute-unit limits, archive data, dedicated capacity |
| NFT marketplace | Mixed reads and writes, occasional spikes | Predictable rate limit, burst handling |
Once you know your workload, ask each provider three questions:
- What is the rate limit? Is it requests per second, per minute, or per day? Is it per IP or per API key?
- How is the limit enforced? Are there separate limits for HTTP and WebSocket? Do heavy methods count more?
- What happens when you exceed the limit? Do you get HTTP 429 responses, dropped connections, or silent throttling?
For a production app, you want clear answers to all three. If a provider cannot explain its rate limiting model, that is a red flag.
How Solana RPC providers structure rate limits
Most providers use one of three models:
- Requests per second (RPS): A simple cap on the number of requests per second. Easy to understand, but it does not account for the cost of each request.
-
Compute units (CU): Each method has a weight based on how expensive it is to process.
getBalancemight cost 1 CU, whilegetProgramAccountsmight cost 100 CU. Your limit is a CU budget per second or per day. - Daily request quota: A total number of requests per day, often combined with a per-second burst limit.
Solana's RPC methods vary widely in cost. A getLatestBlockhash is cheap, but a getProgramAccounts with a large data slice can be expensive for the node. Providers that use CU-based limits are better at protecting their infrastructure, but they can be harder for developers to predict.
WebSocket subscriptions are often limited separately. Some providers cap the number of concurrent connections, while others limit the number of subscriptions per connection. If your app relies on real-time updates, check these limits carefully.
Usage tiers: what providers typically offer
Most Solana RPC providers offer a free tier and several paid tiers. The free tier is usually enough for development and small projects, but it often has strict limits that make it unsuitable for production.
Common tier structures include:
- Free tier: Low RPS (e.g., 5-10), limited daily requests, no WebSocket or archive access.
- Pay-as-you-go: You pay for what you use, with a base rate per million requests. Good for variable traffic.
- Monthly subscription: A fixed price for a set number of requests per month, with overage charges. Predictable for steady traffic.
- Dedicated node: You get a private endpoint with no shared rate limit. The node is reserved for your traffic, so you can sustain high throughput without hitting shared limits.
OnFinality offers both shared RPC access and dedicated nodes. The shared service provides a public endpoint for development, while dedicated nodes give you a private endpoint with your own capacity. For production workloads with sustained traffic, a dedicated node is often the right choice.
What to compare when evaluating providers
When you compare Solana RPC providers, do not just look at the headline rate limit. Consider these factors:
Request types and method costs
Some providers count all methods equally, while others weight expensive methods. If your app uses getProgramAccounts heavily, a provider that weights it heavily could be more expensive than one that does not. Ask for a list of method weights or a cost calculator.
WebSocket support
Solana apps often use WebSocket subscriptions for real-time account updates. Check whether the provider supports WebSocket, how many concurrent connections you can have, and whether subscriptions count against your rate limit.
Archive data and historical access
If you need historical state or transactions, you need an archive node. Not all providers offer archive data, and those that do may charge a premium. Check whether the archive is full or partial, and how far back it goes.
Geographic distribution
Latency matters for trading and other time-sensitive apps. Providers with endpoints in multiple regions can reduce latency by serving requests from a nearby location. Check where the provider's nodes are located and whether you can choose a region.
Failover and redundancy
If a provider's endpoint goes down, can you fail over to another provider? Some providers offer multiple endpoints or automatic failover. For production apps, a single point of failure is risky.
Rate limit errors and how to handle them
When you exceed a rate limit, you will typically see an HTTP 429 response. The response may include a Retry-After header indicating how long to wait. Your client should handle this gracefully by backing off and retrying.
Here is a simple example of handling rate limits in JavaScript:
async function rpcCall(url, body, retries = 3) {
for (let i = 0; i < retries; i++) {
const response = await fetch(url, {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify(body)
});
if (response.status === 429) {
const retryAfter = response.headers.get('Retry-After') || 1;
await new Promise(resolve => setTimeout(resolve, retryAfter * 1000));
continue;
}
return response.json();
}
throw new Error('Rate limit exceeded after retries');
}
For WebSocket connections, rate limits may manifest as dropped connections or missed messages. Implement reconnection logic with exponential backoff.
Comparing OnFinality with other Solana RPC providers
OnFinality provides Solana RPC access through both shared and dedicated options. The shared endpoint is suitable for development and light production use, while dedicated nodes offer dedicated capacity for high-throughput workloads.
| Provider | Rate limit model | Free tier | Dedicated nodes | WebSocket | Archive |
|---|---|---|---|---|---|
| OnFinality | Per-second and per-day limits on shared; dedicated nodes have no shared limits | Yes | Yes | Yes | Yes (on dedicated) |
| Provider A | RPS-based | Yes | Yes | Yes | Extra cost |
| Provider B | CU-based | Yes | No | Limited | No |
| Provider C | Daily quota | Yes | Yes | Yes | Yes |
This table is illustrative. Always check the provider's current documentation for exact limits and pricing. OnFinality's RPC pricing page lists current plans, and the supported networks page shows which networks are available.
Migration checklist: switching Solana RPC providers
If you are switching providers, follow this checklist to avoid downtime:
- Audit your current usage: Measure your RPS, daily requests, and WebSocket connections over a week.
- Identify heavy methods: Use logs to see which methods consume the most requests.
- Test the new provider: Run a load test against the new endpoint to verify it handles your traffic.
- Update your configuration: Change the RPC URL in your app. For example, in a Solana web3.js connection:
import { Connection } from '@solana/web3.js';
const connection = new Connection('https://solana.api.onfinality.io/public', {
wsEndpoint: 'wss://solana.api.onfinality.io/public-ws',
commitment: 'confirmed'
});
- Monitor for errors: Watch for 429 responses and WebSocket disconnects during the transition.
- Keep the old provider as a fallback: Configure failover in your app to switch if the new provider has issues.
Key Takeaways
- Rate limits vary by provider and can be based on requests per second, compute units, or daily quotas.
- Match your workload to a tier: light apps can use free tiers, but production apps need predictable limits.
- WebSocket and archive access are often limited separately; check those limits before committing.
- OnFinality offers both shared and dedicated Solana RPC options, with a public endpoint for development and dedicated nodes for high-throughput workloads.
- Always test a new provider with your actual traffic patterns before switching.
Frequently Asked Questions
What is a typical free tier rate limit for Solana RPC?
Free tiers often allow 5-10 requests per second and a limited number of daily requests. They are suitable for development but not for production traffic.
How do I know if I need a dedicated Solana node?
If you consistently hit rate limits on a shared plan, or if you need low latency and high throughput for trading or indexing, a dedicated node gives you dedicated capacity without shared throttling.
Does OnFinality support WebSocket for Solana?
Yes, OnFinality provides a WebSocket endpoint for Solana. Check the Solana network page for the latest details.
Can I use OnFinality's public Solana endpoint for production?
The public endpoint is shared and rate-limited, so it is best for development and testing. For production, consider a dedicated node or a paid shared plan with higher limits.
What should I do if I get HTTP 429 errors?
Implement retry logic with exponential backoff and respect the Retry-After header. If you consistently hit limits, upgrade your plan or move to a dedicated node.
Related resources
Originally published at OnFinality.
Top comments (0)