Logo
New RPC users get 35% off their first monthView the offer
RPC Assistant

Top RPC solutions with dedicated node access for Solana: how do you evaluate them?

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.

ProviderAccess modelSolana method coverage to confirmWebSocket supportFailover optionsWhere it fits
OnFinalityRPC API plus dedicated node infrastructureConfirm current method list and any per-method limits on the Solana network pageYes, public WS endpoint available; dedicated WS on requestMultiple endpoints and provider-level redundancyTeams that want to start on shared RPC and scale into dedicated nodes
Managed RPC providersPooled or tiered API accessVaries; heavy methods often gatedUsually yes on paid tiersProvider-managedTeams that want a fully managed API with no node operations
Cloud-hosted self-run nodesYou run the nodeFull controlYou configure itYou build itTeams with strong infra skills and a reason to own the node
Public endpointsFree shared accessRestrictedLimited or noneNonePrototyping 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.

SettingValue
Chain nameSolana Mainnet
Native currencySOL (9 decimals)
HTTP RPC URLhttps://solana.api.onfinality.io/public
WebSocket RPC URLwss://solana.api.onfinality.io/public-ws
Block explorerhttps://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 getProgramAccounts frequently.
  • 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:

  1. 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.
  2. Test in staging first. Point a staging environment at the dedicated endpoint and run your full test suite before touching production.
  3. Keep a fallback endpoint. Configure a secondary endpoint in your client so a single provider issue does not take down your app.
  4. Update monitoring. Add probes for slot height, request latency, error rates, and WebSocket reconnects.
  5. 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:

SymptomLikely causeWhat to check
getProgramAccounts times outMethod restricted or too broad a filterAdd dataSlice or filters; confirm method support on your tier
WebSocket disconnects frequentlyConnection limits or idle timeoutsAdd reconnect logic; check subscription count
Slot height lags behind other providersNode sync or routing issueCompare slot height across providers; contact support
Rate-limit errors during spikesTier limits reachedReview request mix; consider dedicated node access
Inconsistent results across callsReading from different nodesPin 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 getProgramAccounts and 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.

RPC Knowledge Base

Related RPC details

Never Worry about Infrastructure Again

OnFinality takes away the heavy lifting of DevOps so you can build smarter and faster.

Get Started