Summary
Choosing the right Solana RPC provider is critical for the performance and reliability of your dApp, trading bot, or indexing service. This guide explains the key differences between public, shared, and dedicated Solana RPC endpoints, and provides a practical evaluation framework to help you match infrastructure to your project's workload, latency, and data requirements.
We cover essential criteria like throughput, WebSocket support, archive data access, and failover strategies, and show how to compare providers like OnFinality against other options. Whether you're building a DeFi protocol, NFT marketplace, or analytics platform, you'll learn what to test before committing to a provider.
Solana RPC Selection: What Your Project Actually Needs
Before comparing providers, define the workload your Solana project will place on RPC infrastructure. A simple NFT minting dApp has different requirements than a high-frequency trading bot or a data indexer scanning historical state.
Ask yourself these questions:
- What is your request rate? A few requests per minute from a frontend is very different from thousands of requests per second from a backend service.
- Do you need real-time data? WebSocket subscriptions for account or program updates are essential for live dashboards and trading applications.
- Do you need historical data? Querying past transactions, account states, or program logs requires archive nodes, which store the full history of the chain.
- What is your latency budget? For user-facing applications, slow RPC responses directly impact user experience. For trading bots, latency can mean missed opportunities.
- What is your reliability requirement? If your service goes down when the RPC provider has an outage, you need a provider with strong redundancy and failover.
Answering these questions will guide you toward the right type of Solana RPC: public, shared, or dedicated.
Solana RPC Provider Types: Public, Shared, and Dedicated
Solana RPC providers generally fall into three categories, each with different tradeoffs.
Public RPC Endpoints
Public endpoints are free, open to anyone, and often operated by the Solana Foundation or community members. They are great for development and testing, but they are not suitable for production workloads.
- Pros: Free, easy to use, no signup required.
- Cons: Rate limits, unreliable under load, no SLA, often lack WebSocket support, and can be blocked or throttled.
Shared RPC Services
Shared RPC services, like OnFinality's public and paid tiers, provide managed infrastructure that is shared among many users. They offer better reliability and performance than public endpoints, with features like load balancing, caching, and WebSocket support.
- Pros: Higher throughput than public, more reliable, often include developer tools and analytics, scalable.
- Cons: Still subject to rate limits and potential noisy neighbors, less control over the underlying node.
Dedicated Nodes
Dedicated nodes give you exclusive access to a Solana node or cluster. This is the highest level of performance and control, ideal for high-throughput applications, large-scale indexers, or projects with strict compliance requirements.
- Pros: No shared resources, full control over node configuration, consistent performance, can handle very high request volumes.
- Cons: More expensive, requires more operational knowledge to manage.
Provider Evaluation Matrix for Solana RPC
When comparing Solana RPC providers, use a structured evaluation matrix. Here's a table with the key criteria to consider:
| Criterion | What to Check | Why It Matters |
|---|---|---|
| Throughput & Rate Limits | Maximum requests per second (RPS), burst allowances, and fair-use policies | Determines if the provider can handle your peak load without throttling |
| Latency | Geographic distribution of nodes, connection quality, and response times | Low latency is critical for real-time applications and trading |
| WebSocket Support | Availability of wss:// endpoints, subscription types, and connection limits | Needed for real-time updates and event-driven architectures |
| Archive Data | Access to historical state and transactions, retention period | Required for analytics, backtesting, and compliance |
| Reliability & Uptime | Historical uptime, redundancy, failover mechanisms, and SLAs | Ensures your application remains available |
| Developer Experience | Documentation, SDKs, debugging tools, and API key management | Reduces development time and operational overhead |
| Pricing Model | Pay-as-you-go vs. subscription, cost per request, and overage charges | Affects your operational costs as you scale |
| Support | Response time, availability of dedicated support, and community resources | Critical for resolving issues quickly in production |
How to Test a Solana RPC Provider Before Committing
Don't just take a provider's word for it. Run your own benchmarks and tests to see if they meet your requirements.
1. Check Basic Connectivity
Use curl to send a simple JSON-RPC request to the provider's endpoint. For example, using OnFinality's public Solana endpoint:
curl https://solana.api.onfinality.io/public \
-X POST \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","id":1,"method":"getHealth"}'
A healthy response should return {"jsonrpc":"2.0","result":"ok","id":1}.
2. Measure Latency and Throughput
Use a tool like hey or wrk to send a burst of requests and measure response times and error rates. Compare results across different providers and times of day.
3. Test WebSocket Subscriptions
If you need real-time data, test the WebSocket endpoint. Here's a simple Node.js script to subscribe to account updates:
const WebSocket = require('ws');
const ws = new WebSocket('wss://solana.api.onfinality.io/public-ws');
ws.on('open', function open() {
ws.send(JSON.stringify({
jsonrpc: '2.0',
id: 1,
method: 'accountSubscribe',
params: [
'9xQeWvG816bUx9EPjHmaT23yvVM2ZWbrrpZb9PusVFin',
{ encoding: 'base64', commitment: 'finalized' }
]
}));
});
ws.on('message', function incoming(data) {
console.log(data.toString());
});
4. Verify Archive Data Access
If you need historical data, try querying an old slot or transaction. For example, use getBlock with a slot number from a few days ago. If the provider returns an error, they may not have archive data.
OnFinality's Solana RPC: A Closer Look
OnFinality offers both shared and dedicated Solana RPC options. Our public endpoint is a good starting point for development, but for production projects, we recommend our dedicated node service.
Here's what to consider when evaluating OnFinality for your Solana project:
- Global Infrastructure: Our nodes are distributed across multiple regions, reducing latency for users worldwide.
- WebSocket Support: We provide
wss://endpoints for real-time applications. - Archive Nodes: We offer archive data for Solana, enabling historical queries.
- Scalability: Our shared service can handle significant traffic, and dedicated nodes provide even more headroom.
- Transparent Pricing: Check our RPC pricing page for details.
We encourage you to test our endpoints and compare them with other providers to see if we meet your needs.
Common Solana RPC Pitfalls and How to Avoid Them
Even with a good provider, you can run into issues. Here are some common pitfalls and how to avoid them:
- Rate Limiting: If you exceed the provider's rate limit, you'll get HTTP 429 errors. Implement retry logic with exponential backoff, and consider using a dedicated node if you consistently hit limits.
- WebSocket Disconnections: WebSocket connections can drop. Implement reconnection logic and handle subscription resubscription.
- Incorrect Commitment Levels: Solana has different commitment levels (
processed,confirmed,finalized). Using the wrong one can lead to inconsistent data. Choose the level that matches your use case. - Large Responses: Querying large blocks or accounts can return huge payloads, slowing down your application. Use filters and pagination where possible.
- Not Using Archive Nodes: If you need historical data, ensure your provider offers archive nodes. Otherwise, you'll only have access to recent state.
Making the Final Decision
After evaluating providers against your requirements, you should have a clear picture of which one fits your project. Here's a quick decision guide:
- For development and testing: Use a public endpoint or a free tier from a managed provider.
- For production dApps with moderate traffic: A shared RPC service like OnFinality's public or paid tier is often sufficient.
- For high-throughput applications, trading bots, or data-intensive services: Consider a dedicated node to ensure consistent performance and avoid noisy neighbors.
Remember that your needs may change as your project grows. Choose a provider that allows you to scale up easily, whether that's upgrading your plan or moving from shared to dedicated infrastructure.
Key Takeaways
- Define your workload requirements before choosing a Solana RPC provider.
- Public endpoints are not suitable for production; shared or dedicated services are better.
- Evaluate providers based on throughput, latency, WebSocket support, archive data, reliability, and pricing.
- Test providers with your own benchmarks before committing.
- OnFinality offers both shared and dedicated Solana RPC options to match different project needs.
Frequently Asked Questions
What is the best Solana RPC provider?
The best provider depends on your project's specific needs. Evaluate factors like throughput, latency, archive data, and pricing. OnFinality offers competitive options for both shared and dedicated Solana RPC.
Can I use a public Solana RPC endpoint for production?
Public endpoints are not recommended for production due to rate limits and reliability issues. Use a managed service or dedicated node for production workloads.
What is the difference between shared and dedicated Solana RPC?
Shared RPC services pool resources among many users, offering cost efficiency but potential performance variability. Dedicated nodes provide exclusive access, ensuring consistent performance and higher throughput.
Does OnFinality support WebSocket for Solana?
Yes, OnFinality provides WebSocket endpoints for Solana, allowing real-time subscriptions. Check our Solana network page for details.
How can I test a Solana RPC provider?
Use curl to send basic JSON-RPC requests, run load tests to measure throughput, and test WebSocket subscriptions. Verify archive data access by querying historical slots.