Summary
Solana RPC providers fall into three practical tiers: public endpoints, shared managed RPC, and dedicated nodes. Public endpoints like https://api.mainnet-beta.solana.com are free but rate-limited and designed for testing. Shared managed RPC gives your app an API key, clearer limits, WebSocket support, and dashboards without operating a node. Dedicated Solana nodes provide isolated capacity and more predictable performance for high-volume or latency-sensitive workloads. Choose based on traffic shape, WebSocket needs, error visibility, and whether a workload can tolerate shared capacity. Start with a shared endpoint for early production, move to dedicated when one workload consumes most of your request budget, backend indexing becomes heavy, or user-facing transactions need stronger isolation. Use Devnet for staging and test SOL from the official faucet, then replicate the same connection patterns on mainnet. This page provides a comparison framework, checklist, and migration guidance so you can move from public to shared to dedicated infrastructure as your Solana application grows. Always verify current rate limits and endpoint availability before production.
Key Takeaways
- Public endpoints are for testing; shared managed RPC adds limits, support, and dashboards for production.
- Move to dedicated nodes when traffic, isolation, or operational control becomes critical.
- Test WebSocket subscriptions and Devnet parity before committing.
- Compare cost models against actual workload, not just list price.
What Types of Solana RPC Providers Are Available?
Solana RPC access generally comes in three forms: public endpoints, shared managed RPC, and dedicated nodes. Each trades off cost, control, and operational overhead differently.
Public endpoints are the cluster URLs published by Solana. They are free, rate-limited, and intended for development, testing, and small experiments. Shared managed RPC providers operate multi-tenant fleets and give you API keys, usage dashboards, and WebSocket support without running a node. Dedicated Solana nodes are single-tenant resources with isolated capacity, custom configuration, and more predictable behavior.
- Public RPC: Free, community endpoints such as Solana public RPC guide and https://api.devnet.solana.com.
- Shared managed RPC: Provider-managed endpoints with API keys, rate limits, and basic observability.
- Dedicated RPC: Isolated node capacity for a single team, with the option to tune for specific workloads.
Solana RPC Provider Comparison Table
Use this table to compare the three provider types on the dimensions that matter most for production workloads.
| Criterion | What to check | Why it matters |
|---|---|---|
| Access model | No API key (public), API key (shared), or dedicated endpoint (dedicated) | Affects rate limit visibility, security, and the ability to isolate traffic. |
| Rate limits | Public: enforced and can change; Shared: provider-defined, visible in dashboard; Dedicated: capacity-based | Hard caps can stall an app during traffic spikes; dedicated capacity reduces this risk. |
| WebSocket support | Public: available but not production-grade; Shared: usually supported with reconnect expectations; Dedicated: more predictable | Real-time features like subscriptions depend on stable WebSocket connections. |
| Operations | Public: no dashboards or support; Shared: usage analytics and tickets; Dedicated: deeper monitoring and custom config | Incident diagnosis requires request-level context and support. |
| Cost model | Public: free; Shared: monthly or usage-based; Dedicated: node rental or custom quote | Align cost with actual workload and scaling path. |
| Best for | Public: prototyping, devnet testing; Shared: early production, moderate traffic; Dedicated: high-volume, latency-sensitive, indexing | Choosing the right tier avoids overpaying or hitting infrastructure walls. |
When Public RPC Is Enough
Public endpoints are suitable for development, tutorials, CLI checks, and low-stakes scripts. They are the default when following Solana documentation or testing with Devnet before connecting to mainnet.
Use https://api.devnet.solana.com with test SOL from the official faucet at https://faucet.solana.com for staging. For mainnet experiments, https://api.mainnet-beta.solana.com works but should not be treated as production infrastructure.
Public RPC limits are enforced and can change. If you start seeing 429 responses or intermittent failures during a test, that is a signal to move to a shared managed endpoint. For more details on public endpoints, see the Solana public RPC guide.
- Learning Solana with CLI or small scripts.
- Testing Devnet deployments and wallet connections.
- Running short-lived batch jobs where rate limits are understood.
- Checking chain state without building a product feature.
When You Need a Dedicated Solana Node
Dedicated nodes make sense when the workload needs isolated capacity, custom configuration, predictable behavior during traffic spikes, or separation from noisy neighbors. Common signals include high-volume getProgramAccounts calls, heavy backend indexing, trading bots, NFT mints, or user-facing transaction flows that cannot tolerate rate-limit errors.
Instead of treating every request the same, you can isolate a heavy worker or analytics job from the main app traffic. OnFinality offers dedicated Solana infrastructure as a step up from shared RPC; see the dedicated Solana node page for current configuration and region options.
Dedicated does not automatically mean unlimited throughput; it means the node's resources belong to your team and can be tuned to your workload. Verify capacity and monitoring details with the provider.
- High-throughput transaction submission or account indexing.
- Latency-sensitive trading or MEV-related workloads.
- Production launches where burst capacity must be predictable.
- Teams that need custom software versions or deeper operational control.
How to Choose a Solana RPC Provider
Start by writing down the methods your app calls most: getAccountInfo, getProgramAccounts, simulateTransaction, sendTransaction, getSignaturesForAddress, and any WebSocket subscriptions. Then estimate traffic shape: frontend reads, backend jobs, bot traffic, and peak events.
Test every candidate endpoint from the region your app runs in. Use the same code paths you will use in production, including WebSocket reconnects. Compare error behavior under load, not just average latency.
Check Devnet parity: the provider should give you a reliable Solana Devnet endpoint for staging, with similar method support to mainnet. Then plan a migration path: start with shared RPC, watch request analytics, and move specific workloads to dedicated capacity when needed. See the Solana Devnet guide for testing workflows.
- List required methods and subscription types.
- Model normal and peak request volumes.
- Test from production-like regions.
- Confirm WebSocket reconnection behavior.
- Compare rate limits and cost against real usage.
Solana RPC Provider Checklist
Use this checklist before sending production traffic to any Solana RPC endpoint.
Next steps: Fastest Solana RPC guide · Mainnet, Devnet & Testnet guide.
| Criterion | What to check | Why it matters |
|---|---|---|
| Access model | Public, shared, or dedicated; matches traffic and isolation needs | Determines rate limit behavior and operational control. |
| Endpoint coverage | Mainnet-beta, Devnet, WebSocket endpoints | Both environments must work for CI/CD and staging. |
| Rate limits | 429 handling, burst policy, cost to raise limits | Hard caps can stall a launch or backend job. |
| Method support | Required JSON-RPC methods and archive depth | Missing methods create workarounds and extra infrastructure. |
| WebSocket stability | Subscription reconnects and message ordering | Real-time features depend on reliable streams. |
| Operations | Dashboards, logs, support response | Incident diagnosis without guessing what the endpoint saw. |
| Pricing | Unit-based, monthly, or node rental; overage rules | Align cost with actual workload and scaling path. |
| Migration path | Ability to move from shared to dedicated | Reduces re-platform risk when traffic grows. |
Frequently Asked Questions
What is the difference between public, shared, and dedicated Solana RPC?
Public endpoints are free and rate-limited, shared managed RPC adds API keys and dashboards, and dedicated nodes give your team isolated capacity. Choose shared for early production and dedicated when traffic or isolation needs grow.
When should I move from shared to dedicated Solana RPC?
Move to dedicated when you consistently hit rate limits on shared, need predictable latency for trading or mints, run heavy indexing, or want stronger operational control. Start with shared and isolate specific workloads first.
Does OnFinality support Solana WebSocket and archive queries?
OnFinality provides Solana HTTP and WebSocket endpoints, with archive support and regions such as N. Virginia and Hong Kong. Check the current Solana network page for endpoint details and available configurations.
Is Solana Devnet a reliable testing environment?
Solana Devnet is designed for development and testing, uses test SOL from the official faucet, and is not production. It is useful for staging, CI, and contract testing, but do not rely on it for real assets or performance expectations.
How do I test a Solana RPC provider before committing?
Use the same method calls and WebSocket subscriptions your app uses, run them from your production region, and watch for 429s, latency spikes, and reconnects. Compare dashboards and support response during a trial.
Ethereum
Solana
Polygon
Base
Arbitrum
BNB Chain
Polkadot
Optimism
