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

What dedicated node access features should Solana developers look for?

Summary

Dedicated Solana RPC nodes give your dApp exclusive access to a single node instance, avoiding the noisy-neighbor effects of shared endpoints. Key features to evaluate include dedicated compute and bandwidth, configurable rate limits, WebSocket support, archive access, and failover options. This article explains what these features mean in practice and how to choose the right setup for production workloads.

Quick decision guide: when do you need a dedicated Solana node?

If your application sends a steady stream of transactions, subscribes to real-time account updates, or runs analytics that scan large ledger ranges, a shared public endpoint will eventually become a bottleneck. A dedicated Solana RPC node gives you a private instance with predictable performance and configurable access. Before you commit, decide which of these scenarios matches your workload:

  • High transaction volume: You need to send many transactions per second without hitting shared rate limits.
  • Real-time data: You rely on WebSocket subscriptions for account or program updates.
  • Historical queries: You need getSignaturesForAddress or getTransaction for older slots, which requires archive data.
  • Compliance or privacy: You want to avoid sharing IP addresses or request patterns with other users.

If any of these apply, a dedicated node is worth evaluating. For lower-volume development or testing, a shared endpoint may be sufficient. OnFinality offers both shared and dedicated options; you can compare plans on RPC pricing and see supported networks on supported RPC networks.

What does "dedicated" mean for Solana RPC?

A dedicated Solana RPC node is a single node instance that your project uses exclusively. Unlike shared endpoints, where hundreds of applications hit the same node, a dedicated node gives you:

  • Isolated compute and bandwidth: No noisy neighbors competing for CPU, memory, or network.
  • Custom rate limits: You can set limits that match your application's needs, rather than a one-size-fits-all shared limit.
  • Direct WebSocket connections: Subscribe to account and program updates without multiplexing with other users.
  • Access to node configuration: Some providers allow you to tune node settings, such as enabling archive mode or adjusting snapshot intervals.

Dedicated nodes are not a magic bullet. They still require proper client-side handling of rate limits and retries. But they remove the unpredictability that comes from sharing infrastructure.

Key features to compare in a dedicated Solana RPC provider

When evaluating providers, look beyond the headline price. The following features determine whether a dedicated node will actually meet your production needs.

FeatureWhat to checkWhy it matters
Rate limitsAre limits per second, per minute, or per day? Can you increase them?Prevents throttling during traffic spikes.
WebSocket supportIs wss available? Are subscriptions stable?Real-time apps need persistent connections.
Archive dataDoes the node store historical state? How far back?Needed for getTransaction and getSignaturesForAddress queries.
FailoverDoes the provider offer automatic failover to a backup node?Ensures availability if the primary node fails.
Geographic locationWhere are the nodes hosted?Latency matters for global users.
SupportIs there a dedicated support channel?Helps resolve issues quickly in production.

OnFinality's dedicated nodes are designed for production workloads. You can request a dedicated node through the dedicated node service and configure it to your needs.

How to connect to a dedicated Solana RPC node

Once you have a dedicated node, you'll receive an HTTP URL and a WebSocket URL. The public OnFinality Solana endpoint is https://solana.api.onfinality.io/public for HTTP and wss://solana.api.onfinality.io/public-ws for WebSocket. Your dedicated endpoint will be similar but private to your project.

Here's a basic curl example to check the node's health and get the current slot:

curl https://solana.api.onfinality.io/public -X POST -H "Content-Type: application/json" -d '
  {
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getHealth"
  }
'

For a dedicated node, replace the URL with your private endpoint. You can also use the WebSocket endpoint for real-time subscriptions:

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: 'accountSubscribe',
    params: [
      '9xQeWvG816bUx9EPjHmaT23yvVM2ZWbrrpZb9PusVFin',
      { encoding: 'base64', commitment: 'finalized' }
    ]
  }));
});

ws.on('message', (data) => {
  console.log(data.toString());
});

Rate limits and throttling: what to expect

Dedicated nodes typically come with higher rate limits than shared endpoints, but they are not unlimited. Providers enforce limits to protect the node from abuse. Common limits include requests per second (RPS) and concurrent WebSocket connections.

When you exceed a rate limit, the node returns a 429 HTTP status or a JSON-RPC error. Your client should handle these gracefully with exponential backoff. Here's a simple retry pattern in JavaScript:

async function rpcCall(method, params) {
  const response = await fetch('https://solana.api.onfinality.io/public', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ jsonrpc: '2.0', id: 1, method, params })
  });
  if (response.status === 429) {
    await new Promise(resolve => setTimeout(resolve, 1000));
    return rpcCall(method, params);
  }
  return response.json();
}

WebSocket subscriptions and real-time data

Solana's WebSocket API is essential for applications that need live updates, such as order books, token balances, or program events. Dedicated nodes provide a stable WebSocket connection without the risk of being disconnected due to shared load.

Key subscription methods include:

  • accountSubscribe – watch a specific account's state.
  • programSubscribe – watch all accounts owned by a program.
  • logsSubscribe – receive transaction logs.
  • slotSubscribe – get notifications when a new slot is confirmed.

When using WebSockets, always implement reconnection logic. Network interruptions happen, and your client should automatically reconnect and resubscribe.

Archive access for historical queries

Solana's default node configuration only keeps recent state. If your application needs to query historical transactions or signatures, you need an archive node. Archive nodes store the full ledger history, enabling methods like getTransaction for old slots.

Not all dedicated nodes include archive access. Check with your provider whether archive data is included or available as an add-on. OnFinality can provision archive nodes for Solana; contact us through the dedicated node service for details.

Failover and high availability

A single dedicated node is a single point of failure. If the node goes down, your application loses access. Providers may offer failover options, where a secondary node automatically takes over if the primary fails.

When evaluating failover, consider:

  • Automatic vs manual failover: Does the provider detect failures and switch automatically?
  • Data consistency: Does the backup node have the same state as the primary?
  • Connection pooling: Can your client handle multiple endpoints?

OnFinality's infrastructure includes monitoring and failover capabilities. For production applications, we recommend discussing your requirements with our team.

Common pitfalls when using dedicated Solana RPC nodes

Even with a dedicated node, developers often run into issues. Here are some common pitfalls and how to avoid them:

  • Not handling rate limits: Even dedicated nodes have limits. Implement retries with backoff.
  • Ignoring WebSocket reconnection: Always code for reconnection and resubscription.
  • Using the wrong commitment level: processed is faster but less reliable; finalized is safer for financial apps.
  • Overloading the node with heavy queries: getProgramAccounts with no filters can be expensive. Use filters or indexers.
  • Not monitoring node health: Set up alerts for response times and error rates.

Key Takeaways

  • Dedicated Solana RPC nodes provide isolated compute, configurable rate limits, and stable WebSocket connections.
  • Evaluate providers on rate limits, archive access, failover, and support.
  • Use the public endpoint for testing, but switch to a dedicated node for production workloads.
  • Implement robust client-side handling for rate limits and WebSocket reconnections.
  • OnFinality offers dedicated Solana nodes; compare options on RPC pricing and explore supported networks.

Frequently Asked Questions

What is the difference between a shared and dedicated Solana RPC node?

A shared node is used by multiple applications, which can cause performance variability. A dedicated node is exclusively for your project, providing consistent performance and customizable limits.

Do I need a dedicated node for a small dApp?

Not necessarily. If your traffic is low and you don't need real-time data, a shared endpoint may suffice. As your user base grows, you can upgrade to a dedicated node.

Can I use a dedicated node for Solana devnet?

Yes, dedicated nodes are available for devnet as well. You can request one through the Solana Devnet page.

How do I get a dedicated Solana RPC node from OnFinality?

Visit the dedicated node service page to request a node. You can specify your requirements, and the team will provision it for you.

What is the public Solana RPC endpoint for testing?

You can use https://solana.api.onfinality.io/public for HTTP and wss://solana.api.onfinality.io/public-ws for WebSocket. These are for testing only; production apps should use a dedicated endpoint.

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