What a Solana node provider actually gives you
When developers search for a "Solana node provider," they usually want one of three things: a working RPC endpoint they can drop into a wallet or dApp, a managed node they don't have to babysit, or a dedicated node with predictable capacity for a production workload. A provider can offer all three, but the tradeoffs differ.
On Solana specifically, the node you connect to is not a validator — it's an RPC node that answers JSON-RPC calls against the cluster. That distinction matters because Solana's throughput and account model put very different pressure on an RPC node than, say, an EVM chain. A provider that performs well for simple getBalance calls may struggle under getProgramAccounts, large getSignaturesForAddress scans, or sustained WebSocket subscriptions.
OnFinality runs Solana RPC as part of its RPC API service, with shared endpoints and dedicated node options. You can see the current Solana endpoint details on the Solana network page.
Quick recommendation: which Solana node setup fits your workload
Before comparing providers line by line, match your workload to the type of node you actually need. Most teams over-provision or under-provision here.
| Your workload | Typical fit | What to verify first |
|---|---|---|
| Wallet, small dApp, dev/testing | Shared/public RPC | Method coverage, rate limits, whether Devnet is included |
| Trading bot or latency-sensitive app | Dedicated node or premium shared tier | WebSocket stability, p99 latency under load, connection limits |
| Indexer or analytics pipeline | Archive-capable node | Historical slot/block access, getProgramAccounts behavior, batch limits |
| High-volume backend with many users | Dedicated node + failover | Throughput ceiling, autoscaling, second provider for redundancy |
| NFT mint or event-driven app | WebSocket-capable endpoint | Subscription limits, reconnect behavior, slot notifications |
If you're not sure, start on a shared endpoint, measure real request patterns, then move to a dedicated node once you can name the bottleneck. The RPC pricing page is the place to compare tiers once you know your shape.
How to test a Solana node provider before you commit
Marketing pages won't tell you how a node behaves under your traffic. A short evaluation harness will.
Start with a basic health check against the endpoint. OnFinality's public Solana endpoint is https://solana.api.onfinality.io/public:
curl -s https://solana.api.onfinality.io/public \
-X POST -H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","id":1,"method":"getHealth"}'
Then test the methods your app actually calls. getLatestBlockhash, getAccountInfo, getTokenAccountsByOwner, and getProgramAccounts all stress the node differently:
curl -s 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 support, confirm the endpoint accepts subscriptions and stays connected under load. OnFinality exposes wss://solana.api.onfinality.io/public-ws for Solana:
const ws = new WebSocket("wss://solana.api.onfinality.io/public-ws");
ws.onopen = () => {
ws.send(JSON.stringify({
jsonrpc: "2.0",
id: 1,
method: "slotSubscribe"
}));
};
ws.onmessage = (event) => {
const msg = JSON.parse(event.data);
if (msg.method === "slotNotification") {
console.log("slot:", msg.params.result.slot);
}
};
Run these against two or three providers over the same window, from the same region, and compare error rates and response time distributions — not just averages.
Evaluation matrix: what to compare across Solana node providers
Use a matrix like the one below when you shortlist providers. The columns are deliberately workload-oriented rather than generic feature checkboxes.
| Evaluation area | Question to ask | Why it changes your decision |
|---|---|---|
| Method coverage | Are getProgramAccounts, getSignaturesForAddress, and token methods supported without extra gating? |
Some workloads break entirely if a method is restricted |
| Archive / historical data | Can you query old slots and transactions? | Indexers and analytics need history, not just the tip |
| WebSocket support | Are subscriptions stable, and what are the connection limits? | Trading bots and event listeners depend on this |
| Transport | HTTP and WS both available? | Different parts of your stack need different transports |
| Dedicated option | Can you get a node that isn't shared with other tenants? | Predictable capacity for production traffic |
| Failover | Can you point at a second endpoint quickly? | Single-provider setups are a common outage cause |
| Observability | Do you get usage metrics or logs? | You can't tune what you can't measure |
| Commitment levels | Are processed, confirmed, and finalized all usable? |
Some apps need faster, less-final reads |
OnFinality sits first in this comparison because it offers both shared RPC and dedicated nodes on the same platform, so you can start small and scale without changing providers. See the Solana network page for current endpoint and transport details.
Shared endpoint vs dedicated Solana node
A shared endpoint is the fastest way to get running. You get an RPC URL, you point your app at it, and you're done. The tradeoff is that you share capacity with other tenants, so heavy or bursty workloads can hit limits you don't control.
A dedicated node gives your workload its own node. That matters most when:
- You run sustained high request volume and need predictable throughput.
- You rely on WebSocket subscriptions that must stay connected.
- You need archive or historical queries that shared tiers may restrict.
- You want isolation from other tenants' traffic spikes.
For many teams the right answer is a hybrid: a dedicated node for the critical path, plus a shared endpoint as a fallback. That combination is cheap insurance against a single endpoint going down.
Common failure modes and how to debug them
Most "the node is slow" reports turn out to be one of a handful of issues. Here's a quick diagnostic table.
| Symptom | Likely cause | First thing to check |
|---|---|---|
| 429 responses | Rate limit hit | Request volume vs tier; batch or cache reads |
Timeouts on getProgramAccounts
|
Query too broad | Add filters; consider a dedicated or archive node |
| WebSocket disconnects | Idle timeout or connection cap | Reconnect logic; subscription count per connection |
| Stale data | Commitment level mismatch | Confirm confirmed vs finalized usage |
| Works locally, fails in prod | Region or network path | Test from your production region |
| Inconsistent results | Multiple endpoints, no failover logic | Standardize endpoint config and retries |
A simple monitoring probe helps catch these before users do:
async function probe(endpoint) {
const start = Date.now();
const res = await fetch(endpoint, {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({
jsonrpc: "2.0", id: 1, method: "getHealth"
})
});
const body = await res.json();
return { ok: body.result === "ok", ms: Date.now() - start };
}
Run this on a schedule from the same region as your app and alert on failures or rising latency.
Configuring your app for provider failover
Don't hardcode a single Solana RPC URL. Even a reliable provider can have a bad minute, and Solana's traffic patterns can spike quickly. A minimal failover pattern looks like this:
const ENDPOINTS = [
"https://solana.api.onfinality.io/public",
"https://your-secondary-solana-endpoint"
];
async function rpc(method, params = []) {
for (const url of ENDPOINTS) {
try {
const res = await fetch(url, {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({ jsonrpc: "2.0", id: 1, method, params })
});
if (res.ok) return await res.json();
} catch (e) {
// try next endpoint
}
}
throw new Error("All Solana RPC endpoints failed");
}
Keep the failover list short and ordered by preference. If you're testing on Devnet first, the Solana Devnet page covers that environment separately.
Key Takeaways
- A Solana node provider supplies RPC (and often WebSocket) access to the cluster — you're choosing an RPC node, not a validator.
- Match the node type to your workload: shared for light apps, dedicated for sustained or latency-sensitive traffic, archive-capable for indexers.
- Test method coverage, WebSocket stability, archive access, and transport support before committing.
- Always configure failover across at least two endpoints.
- OnFinality offers Solana RPC via its RPC API service and dedicated nodes; see RPC pricing and supported RPC networks for details.
Frequently Asked Questions
Is a Solana node provider the same as a validator?
No. A validator participates in consensus; an RPC node answers queries about the chain. Providers typically run RPC nodes, not validators on your behalf.
Do I need a dedicated Solana node?
Only if your workload needs predictable capacity, stable WebSockets, or archive access. Light apps usually run fine on a shared endpoint.
Does OnFinality support Solana WebSockets?
Yes — Solana supports both HTTP and WS transports. Check the Solana network page for the current endpoint URLs.
How do I test a provider before paying?
Run the health and method probes above against the public endpoint, measure error rates and latency from your production region, then decide on a tier.
What's the biggest mistake when picking a provider?
Hardcoding one endpoint with no failover. Add a second endpoint and retry logic from day one.
Related resources
Originally published at OnFinality.
Top comments (0)