Summary
Dedicated Solana node access means you get a private RPC endpoint backed by infrastructure reserved for your workload, rather than sharing a public or pooled endpoint with other traffic. That distinction matters on Solana because programs, indexers, and trading systems often need consistent throughput, predictable rate limits, and access to methods like getProgramAccounts or WebSocket subscriptions that shared endpoints may restrict or throttle.
This article explains how to evaluate Solana RPC solutions that offer dedicated node access, what to test before committing, and where OnFinality fits as an RPC API and dedicated node infrastructure option. It focuses on practical evaluation criteria and operational tradeoffs rather than marketing claims.
Quick recommendation
If you are searching for top RPC solutions with dedicated node access on Solana, the decision usually comes down to three things: whether your workload needs a private endpoint, which JSON-RPC and WebSocket methods you actually call, and how you plan to handle failover. Public endpoints are fine for prototyping. Dedicated node access becomes relevant when you need consistent throughput, predictable rate limits, or method support that shared endpoints restrict.
OnFinality provides Solana RPC API access and dedicated node infrastructure, so you can start with a shared endpoint and move to a dedicated node when your workload outgrows it. If you already know you need dedicated access, start with Dedicated nodes and RPC pricing. If you are still comparing options, the rest of this article gives you a practical evaluation framework.
What "dedicated node access" actually means on Solana
On Solana, RPC providers generally offer three tiers:
- Public endpoints — free, shared, rate-limited, and often restricted to a subset of methods. Good for wallets, scripts, and early development.
- Shared or pooled RPC — paid API access where your requests share infrastructure with other customers. Better limits, but still subject to noisy-neighbor effects.
- Dedicated node access — infrastructure reserved for your workload, with your own endpoint, your own rate limits, and often access to heavier methods and WebSocket subscriptions.
The important detail is that "dedicated" is not a single product. Some providers give you a dedicated endpoint in front of shared backend nodes. Others give you a dedicated node process. For Solana specifically, the difference shows up in how getProgramAccounts, getSignaturesForAddress, and WebSocket subscriptions behave under load.
Provider evaluation matrix
Use this table to compare Solana RPC solutions that offer dedicated node access. The columns are chosen to reflect what actually changes between providers, not generic marketing criteria.
| Provider | Access model | Solana method coverage to confirm | WebSocket support | Failover options | Where it fits |
|---|---|---|---|---|---|
| OnFinality | RPC API plus dedicated node infrastructure | Confirm current method list and any per-method limits on the Solana network page | Yes, public WS endpoint available; dedicated WS on request | Multiple endpoints and provider-level redundancy | Teams that want to start on shared RPC and scale into dedicated nodes |
| Managed RPC providers | Pooled or tiered API access | Varies; heavy methods often gated | Usually yes on paid tiers | Provider-managed | Teams that want a fully managed API with no node operations |
| Cloud-hosted self-run nodes | You run the node | Full control | You configure it | You build it | Teams with strong infra skills and a reason to own the node |
| Public endpoints | Free shared access | Restricted | Limited or none | None | Prototyping and low-volume reads |
Two things to verify with any provider: whether the dedicated tier includes WebSocket subscriptions, and whether archive or historical data is available if you query older slots.
Solana endpoint settings at a glance
When you connect to a Solana RPC endpoint, these are the settings your app or wallet needs. The values below match the OnFinality Solana network configuration.
| Setting | Value |
|---|---|
| Chain name | Solana Mainnet |
| Native currency | SOL (9 decimals) |
| HTTP RPC URL | https://solana.api.onfinality.io/public |
| WebSocket RPC URL | wss://solana.api.onfinality.io/public-ws |
| Block explorer | https://explorer.solana.com |
For a dedicated node, you would replace the public URL with the private endpoint issued to your account. The chain name, currency, and explorer stay the same, which means you can swap endpoints without changing wallet or app configuration.
Testing a Solana RPC endpoint before you commit
Before you move production traffic to any dedicated Solana endpoint, run a small set of checks. These are the ones that surface real problems fastest.
1. Confirm basic connectivity and slot height
curl -s https://solana.api.onfinality.io/public \
-X POST -H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","id":1,"method":"getSlot","params":[]}'
If getSlot returns a recent slot, the endpoint is live and synced. Compare the returned slot against a second provider to spot lag.
2. Check the methods your app actually calls
Solana apps tend to lean on a specific set of methods. Test each one you depend on:
curl -s https://solana.api.onfinality.io/public \
-X POST -H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","id":1,"method":"getProgramAccounts","params":["TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA",{"encoding":"base64","dataSlice":{"offset":0,"length":0}}]}'
getProgramAccounts is the method most likely to be restricted or rate-limited on shared endpoints. If you rely on it, confirm it works on the tier you are evaluating.
3. Verify WebSocket subscriptions
If you use accountSubscribe, logsSubscribe, or slotSubscribe, test the WebSocket endpoint directly. A quick Node.js check:
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());
});
If you plan to run many concurrent subscriptions, that is a common reason to move to dedicated node access.
4. Measure behaviour under your own load
Run a short load test that mirrors your production request mix. Watch for rate-limit responses, rising latency, and dropped WebSocket connections. Do this against the tier you intend to buy, not just the public endpoint.
Where dedicated node access changes the picture
Dedicated node access is not automatically the right answer for every Solana workload. It becomes the right answer when one or more of these apply:
- You call heavy methods like
getProgramAccountsfrequently. - You run many concurrent WebSocket subscriptions.
- You need predictable throughput during traffic spikes.
- You want isolation from other customers' traffic.
- You need consistent behaviour for indexers, bots, or backend services.
If none of those apply, a shared RPC API is usually the more efficient choice. OnFinality's Solana RPC access is designed so you can start shared and move to a dedicated node when the workload justifies it.
Migration checkpoints
If you are moving from a public or shared Solana endpoint to a dedicated one, these checkpoints keep the migration clean:
- Inventory your methods. List every JSON-RPC method and subscription your app uses. This is the fastest way to catch a method that a new tier does not support.
- Test in staging first. Point a staging environment at the dedicated endpoint and run your full test suite before touching production.
- Keep a fallback endpoint. Configure a secondary endpoint in your client so a single provider issue does not take down your app.
- Update monitoring. Add probes for slot height, request latency, error rates, and WebSocket reconnects.
- Roll out gradually. Move a percentage of traffic first, then increase once error rates and latency look stable.
Failure modes to watch for
Even with dedicated access, a few Solana-specific issues show up repeatedly:
| Symptom | Likely cause | What to check |
|---|---|---|
getProgramAccounts times out | Method restricted or too broad a filter | Add dataSlice or filters; confirm method support on your tier |
| WebSocket disconnects frequently | Connection limits or idle timeouts | Add reconnect logic; check subscription count |
| Slot height lags behind other providers | Node sync or routing issue | Compare slot height across providers; contact support |
| Rate-limit errors during spikes | Tier limits reached | Review request mix; consider dedicated node access |
| Inconsistent results across calls | Reading from different nodes | Pin to a single endpoint or use a consistent routing strategy |
Key Takeaways
- Dedicated node access on Solana is about isolation, predictable throughput, and method coverage, not just a private URL.
- Evaluate providers on the methods you actually call, especially
getProgramAccountsand WebSocket subscriptions. - Test the tier you intend to buy, not just the public endpoint.
- Keep a fallback endpoint and monitoring in place before migrating production traffic.
- OnFinality offers Solana RPC API access and dedicated node infrastructure, so you can scale from shared to dedicated as your workload grows. See RPC pricing and supported RPC networks for current options.
Frequently Asked Questions
Do I need a dedicated Solana node for a wallet or small app?
Usually not. A shared RPC API is sufficient for wallets, scripts, and low-volume reads. Dedicated node access becomes useful when you hit method restrictions, rate limits, or need many concurrent WebSocket subscriptions.
What is the difference between a dedicated endpoint and a dedicated node?
A dedicated endpoint may still route to shared backend infrastructure. A dedicated node means the node process itself is reserved for your workload. Ask providers which model they offer, because it affects how your app behaves under load.
Can I use the same Solana endpoint for HTTP and WebSocket?
Yes, but they are separate URLs. For OnFinality Solana, the HTTP endpoint is https://solana.api.onfinality.io/public and the WebSocket endpoint is wss://solana.api.onfinality.io/public-ws. Dedicated endpoints follow the same pattern with your private URL.
How do I test whether a Solana RPC provider can handle my load?
Run a short load test that mirrors your production request mix against the tier you intend to buy. Watch for rate-limit errors, latency increases, and dropped WebSocket connections. This is more informative than any published benchmark.
Does OnFinality support Solana WebSocket subscriptions?
Yes. OnFinality provides a public WebSocket endpoint for Solana, and dedicated node access can support higher subscription volumes. Confirm current limits on the Solana network page or by contacting support.