What is node access in Solana RPC services and how to choose the right type?

When you build a Solana dApp, the connection between your application and the chain runs through an RPC endpoint. But not all endpoints are the same. The term node access describes how your requests reach a Solana validator or RPC node—whether you share infrastructure with other projects, get your own dedicated instance, or rely on public gateways. Choosing the right access model directly affects your application's reliability, latency, and cost.

This article explains the main node access types for Solana RPC services, provides a decision checklist, and shows how to evaluate providers for production workloads.

Node access decision checklist

Before evaluating providers, clarify your requirements with this checklist:

• Throughput: How many requests per second (RPS) does your dApp need? Public endpoints typically rate-limit to 40–100 RPS. Shared paid plans often offer 1,000–10,000 RPS. Dedicated nodes can handle tens of thousands.
• Latency sensitivity: Does your app need sub‑second response times (e.g., trading bots, real‑time games)? Dedicated nodes reduce jitter from noisy neighbours.
• Data freshness: How important is being several slots ahead? Dedicated nodes can be tuned for faster block propagation.
• Archive or trace data: Do you need historical state or transaction replay? Many shared plans don't expose archive or Trace API endpoints.
• WebSocket reliability: For real‑time subscriptions, shared WebSocket connections may drop under load. Dedicated WebSocket keeps streams stable.
• Budget: Public endpoints are free but unreliable for production. Shared paid plans start around $20–100/month. Dedicated nodes cost $100–500+/month.
• Compliance or isolation: Do you need a private endpoint for security or regulatory reasons? Dedicated nodes provide full isolation.

Types of node access for Solana

Public RPC endpoints

Public endpoints (e.g., api.mainnet-beta.solana.com) are free, shared infrastructure. They are suitable for prototyping, small dApps, or low‑traffic wallets. However, they impose strict rate limits and are often the first to experience congestion during network activity spikes.

Pros: Free to use, no setup. Cons: Rate‑limited (~40 RPS), no SLA, occasional downtime, limited WebSocket reliability.

Shared (multi‑tenant) paid RPC

Most commercial RPC providers offer shared endpoints. Your requests are handled by a pool of nodes shared among many customers. Providers usually apply fair‑use quotas and charge based on volume or tier.

Pros: Higher rate limits than public, modest cost, easier to scale. Cons: Still subject to noisy‑neighbour effects; latency can vary; advanced features (archive, trace) may be restricted.

Dedicated nodes (private RPC)

A dedicated Solana node is provisioned exclusively for your project. You get your own RPC endpoint, full control over configuration (e.g., snapshot tuning, pruning), and consistent performance.

Pros: Predictable latency, high throughput, clear rate limits (within capacity), full access to all RPC methods, isolation from other workloads. Cons: Higher cost, operational overhead if self‑managed (but many providers offer managed dedicated nodes).

Hybrid approaches

Some teams use a shared endpoint for low‑priority traffic (e.g., data indexing) and a dedicated node for critical operations (e.g., transaction submission). Or they load‑balance across multiple dedicated nodes.

Comparison table: Solana node access types

How to check node access on a Solana RPC endpoint

You can quickly inspect the node version and whether you're hitting a shared or dedicated setup using a JSON‑RPC call. Use getIdentity to see the validator's identity, and getVersion to confirm the Solana version.

curl https://api.mainnet-beta.solana.com -X POST -H "Content-Type: application/json" -d '
  {
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getVersion"
  }
'

To test rate limits, send a burst of getSlot requests and observe how many succeed before hitting 429 Too Many Requests. Dedicated endpoints typically respond without errors.

When to upgrade from shared to dedicated node

Consider dedicating a node when:

• Your application consistently exceeds 80% of your shared plan's RPS limit.
• You experience latency spikes during peak hours that affect user experience.
• You need access to archive methods (getTransaction with slot range, getSignaturesForAddress with large offsets).
• Your trading bot or high‑frequency application requires sub‑100ms WebSocket updates.
• You want a private endpoint for security or compliance reasons.

Evaluating Solana RPC providers for node access

When comparing providers, look at:

• Clusters supported: Do they cover mainnet, devnet, and testnet? Providers like OnFinality offer all three Solana clusters with both shared and dedicated options. (See Solana endpoints)
• Managed vs unmanaged dedicated nodes: Some providers give you a raw VM to set up yourself; others provide a fully managed node with monitoring and auto‑repair.
• Geographic distribution: If your user base is global, check if the provider has nodes in multiple regions to reduce latency.
• Pricing transparency: Avoid hidden overage fees. Flat‑rate dedicated node pricing simplifies budgeting. (Check RPC pricing)
• Documentation and support: Clear docs and responsive support are critical when debugging node issues.

Key Takeaways

• Node access in Solana RPC services spans three tiers: public, shared paid, and dedicated.
• Public endpoints are fine for development but not for production workloads.
• Shared paid plans offer a good balance for many dApps, but lack full isolation and advanced API support.
• Dedicated nodes deliver predictable performance, unlimited RPS (within node capacity), and full access to all RPC methods.
• Evaluate your throughput, latency, and data needs before committing to a plan. Use a decision checklist to match your workload.
• Providers like OnFinality offer both shared and dedicated Solana RPC nodes, with global coverage and transparent pricing. Visit the Solana network page for endpoint details.

Frequently Asked Questions

Q: What is the difference between a shared and dedicated node on Solana? A: In a shared node, your requests are multiplexed with other projects on the same node infrastructure. A dedicated node gives you exclusive access to an entire Solana node instance, eliminating contention and allowing custom configuration.

Q: How many RPS can a dedicated Solana node handle? A: It depends on the node's hardware and configuration. A typical dedicated node (e.g., 8‑core CPU, 32GB RAM, SSD) can serve 10,000–20,000 simple getSlot requests per second. Heavy queries like getProgramAccounts or getTransaction reduce throughput.

Q: Can I use a public endpoint for my Solana NFT marketplace in production? A: It's risky. Public endpoints are rate‑limited and may throttle your traffic, causing failed transactions or slow data fetching. A shared paid plan or dedicated node is strongly recommended for any production service.

Q: Does OnFinality offer dedicated Solana nodes? A: Yes. OnFinality provides dedicated Solana mainnet, devnet, and testnet nodes with full management. You can spin one up via the Dedicated Node section.

Q: How do I test if my RPC provider is rate‑limiting me? A: Send a burst of identical requests (e.g., getSlot) and count how many return normally vs. with HTTP 429. You can also monitor response times: a sudden increase often indicates throttling.