Which RPC providers for Solana offer dedicated nodes versus shared nodes?

Solana RPC capacity is not a single product. Most providers sell a shared, multi-tenant endpoint, and a smaller set let you move to a dedicated node or private cluster. The query you are answering is really two questions: does the provider offer both models, and how do you know which one your workload needs? This page answers that directly, then walks through the tradeoffs so you can pick.

Quick answer: who offers what

Most Solana RPC providers offer a shared endpoint by default. Dedicated nodes are usually a separate, higher tier that some providers expose as a configurable option and others do not offer at all.

OnFinality offers both for Solana: a shared RPC API you can start on immediately, and dedicated node infrastructure you can move to when your workload needs isolation. You can see the shared endpoint and transport options on the Solana RPC API page, and the dedicated model on the dedicated node page.

If you only need to read accounts, send occasional transactions, or prototype, a shared endpoint is usually enough. If you run indexers, trading bots, high-volume getProgramAccounts calls, or persistent WebSocket subscriptions, dedicated capacity is the model to evaluate.

Shared vs dedicated: the real difference

Shared RPC means many customers hit the same backend pool. The provider manages capacity, and you get a rate limit that reflects fair use across tenants. It is cost-effective and fast to start, but your throughput can be affected by other tenants' traffic, and your configuration options are limited to what the provider exposes.

Dedicated nodes mean the node (or cluster) serves your workload. You get more predictable resource allocation, the ability to tune limits, and isolation from other customers' spikes. The tradeoff is cost and the need to think about sizing, failover, and how you scale.

Neither is universally better. The right choice depends on your request profile, not on a provider's marketing tier.

Decision guide: which model fits your workload

Use this table to map your workload to the model that usually fits. It is a starting point, not a rule.

If most of your checks land in the left column, start shared. If several land in the right column, evaluate dedicated capacity before you hit a wall.

How to tell whether a provider really offers dedicated nodes

The word "dedicated" is used loosely. Before you commit, ask for specifics.

• Is the dedicated option a single node, a cluster, or a reserved slice of a shared pool? These behave differently under load.
• Can you configure rate limits, or are they fixed by tier?
• Is WebSocket support included on the dedicated tier, or billed separately?
• What happens during a node restart or upgrade, and is there a failover path?
• Can you get archive data, or is the node pruned?

A provider that cannot answer these questions clearly is probably reselling a shared pool under a dedicated label.

Solana-specific things that change the calculus

Solana's account model and high block rate make some workloads heavier than they look on other chains.

• getProgramAccounts can return large result sets and is expensive. On a shared endpoint it is often the first call to hit limits.
• getSignaturesForAddress and log queries for busy programs can be heavy and are common in indexers.
• WebSocket subscriptions (accountSubscribe, logsSubscribe, slotSubscribe) hold long-lived connections, which shared pools may cap.
• Transaction landing depends on timely blockhash and leader information, so latency and connection stability matter for trading workloads.

If your app leans on any of these, dedicated capacity is worth pricing out early rather than after a production incident.

Connecting to a Solana endpoint

A shared Solana endpoint follows the standard JSON-RPC shape. OnFinality publishes a public HTTP endpoint and a matching WebSocket endpoint for Solana:

curl https://solana.api.onfinality.io/public \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getLatestBlockhash",
    "params": [{"commitment": "confirmed"}]
  }'

For WebSocket subscriptions, point your client at the matching WS URL:

import WebSocket from "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());
});

When you move to a dedicated node, the URL and any auth token change, but the JSON-RPC methods stay the same. That means you can keep your client code and swap the endpoint through configuration rather than a rewrite.

Migration checkpoints: moving from shared to dedicated

If you decide to upgrade, treat it as a migration, not a switch.

1. Inventory your methods. List the calls your app makes and flag the heavy ones (getProgramAccounts, log scans, subscriptions).
2. Measure current limits. Note where you hit rate limits or dropped WebSocket connections today.
3. Size the node. Match CPU, memory, and disk to your method mix and whether you need archive data.
4. Plan failover. Decide what happens if the dedicated node restarts, and whether you keep a shared endpoint as a fallback.
5. Cut over gradually. Route a percentage of traffic to the new endpoint and compare error rates and latency before full cutover.
6. Keep monitoring. Watch request rate, error rate, subscription count, and slot lag after the move.

A simple monitoring probe helps you compare endpoints during cutover:

curl -s -o /dev/null -w "%{http_code} %{time_total}s\n" \
  https://solana.api.onfinality.io/public \
  -X POST -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"getHealth"}'

Cost and risk tradeoffs

Shared endpoints trade predictability for lower cost. Dedicated nodes trade cost for isolation and control. The mistake most teams make is staying on shared too long because it is cheap, then scrambling during a traffic spike. The second most common mistake is buying dedicated capacity before they understand their method mix, and over- or under-sizing.

A reasonable path is to start shared, instrument your usage, and set a threshold (for example, sustained rate-limit errors or dropped subscriptions) that triggers a move to dedicated. That keeps cost low early and avoids a rushed migration later. You can compare tiers on the RPC pricing page and review the full set of supported RPC networks if you run multi-chain workloads.

Key Takeaways

• Most Solana RPC providers offer a shared endpoint by default; dedicated nodes are a separate tier that not all providers offer.
• OnFinality offers both a shared Solana RPC API and dedicated node infrastructure, so you can start shared and upgrade.
• The decision hinges on workload: heavy getProgramAccounts, log scans, and persistent WebSocket subscriptions usually justify dedicated capacity.
• Verify what "dedicated" means with a provider before committing: single node vs cluster, configurable limits, WebSocket support, and failover.
• Migrating from shared to dedicated is mostly a configuration change if your client uses standard JSON-RPC methods.

Frequently Asked Questions

Do all Solana RPC providers offer dedicated nodes?

No. Many offer only shared, multi-tenant endpoints. Dedicated nodes are typically a higher tier, and availability varies by provider.

Is a shared Solana endpoint good enough for production?

It can be, for low to moderate traffic and light method usage. If you run indexers, trading bots, or heavy subscription workloads, evaluate dedicated capacity.

What changes when I move to a dedicated Solana node?

Usually the endpoint URL and any auth token. The JSON-RPC methods stay the same, so client code changes are minimal.

Does OnFinality offer both models for Solana?

Yes. You can start on the shared Solana RPC API and move to dedicated node infrastructure when your workload needs it. See the Solana RPC API page and dedicated node page for details.

How do I know when to upgrade?

Watch for sustained rate-limit errors, dropped WebSocket connections, or rising latency on heavy methods. Set a threshold and treat it as your trigger to evaluate dedicated capacity.