What Is Node Access in Solana RPC Services?

Node Access in Solana RPC Services Decision Checklist

Before selecting a node access plan for your Solana project, consider the following:

• Determine your throughput needs: How many requests per second does your application require? Shared nodes may suffice for low volume, but high-throughput dApps likely need dedicated access.
• Check required RPC methods: Some methods, like getProgramAccounts with large filters, may be restricted on shared nodes. Archive methods require archive node access.
• Evaluate latency sensitivity: Trading or gaming applications need low latency; dedicated nodes with closer geographic placement can help.
• Consider data depth: Do you need historical state (archive) or only recent data (full node)? Archive access is essential for explorers and analytics.
• Budget for scaling: Shared access is cost-effective for development, but dedicated nodes provide predictable performance for production.
• Review provider SLAs: While we avoid absolute claims, understand the terms around rate limits, fair use, and support.

What Is Node Access in Solana RPC Services?

Node access defines how your application connects to the Solana network through an RPC service. In practice, it means the type of node behind the endpoint: shared (multitenant), dedicated (single-tenant), or archive (full historical data). Each model affects request limits, supported APIs, latency, and reliability.

For Solana, RPC services handle transactions, query account states, and read on-chain data. The node access type determines which RPC methods are available and how many requests you can send without hitting rate limits.

Types of Node Access for Solana

1. Shared Node Access

A shared node is used by multiple customers concurrently. The provider manages the infrastructure and rate-limits each consumer to ensure fairness. Shared access is ideal for development, low-traffic dApps, and personal projects. However, it may have restrictions on heavy methods and can suffer from noisy-neighbor issues during peak usage.

2. Dedicated Node Access

A dedicated node gives you exclusive access to a Solana validator or RPC node. You control the configuration, resource allocation, and can customize the node for your workload. Dedicated access offers consistent performance, higher rate limits, and supports any RPC method without shared throttling. It’s recommended for production dApps, DeFi protocols, and data services.

3. Archive Node Access

An archive node stores the entire historical state of Solana, allowing queries for any past slot or account state. Archive access is necessary for block explorers, analytics platforms, and historical data auditing. It typically requires dedicated infrastructure due to storage and compute demands.

Shared vs Dedicated vs Archive Node Access

When to Use Each Access Type

Choose Shared Access When:

• Prototyping or building a proof-of-concept
• Running low-traffic applications (few thousand requests per day)
• Budget is tight and performance guarantees are not critical
• You don't need archive data or heavy RPC methods

Choose Dedicated Access When:

• Your dApp has real users and requires consistent performance
• You need higher rate limits and low latency
• You rely on resource-intensive methods like getProgramAccounts with filters
• You want to avoid noisy-neighbor effects during peak usage

Choose Archive Access When:

• You operate a block explorer, wallet history, or analytics tool
• You need to query historical account states or blocks
• Compliance or auditing requires access to past data

Key Considerations for Production

When moving to production, evaluate how your choice of node access affects your application’s reliability:

• Rate Limiting: Understand the provider’s rate limits. Shared nodes often impose per-second or per-minute caps. Dedicated nodes eliminate these limits or provide much higher thresholds.
• Method Support: Some providers restrict getProgramAccounts on shared nodes because it can be CPU-intensive. Check whether your critical methods are allowed.
• WebSocket Support: For real-time updates (e.g., transaction confirmation, account changes), ensure the access type supports WebSocket connections with stable subscriptions.
• Geographic Distribution: Dedicated nodes can be deployed in the same region as your application servers to minimize latency.
• Backup and Failover: Consider using multiple endpoints from different providers or deploying a dedicated node with a fallback shared endpoint.

Example: Checking Node Access via RPC

You can verify your node access type by calling getIdentity and seeing if the response matches your allocated node. Here’s a simple curl command:

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

If using a dedicated node, the identity will be fixed to your node. On a shared access, the identity may vary or show the provider’s node.

For archive node access, test with a historical method like getBlock for an old slot:

curl -X POST http://api.mainnet-beta.solana.com -H "Content-Type: application/json" -d '
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "getBlock",
  "params": [500]
}
'

If successful, you have archive access. Otherwise, expect an error indicating the slot is not available.

Frequently Asked Questions

Q: What is the difference between node access and RPC endpoint?

An RPC endpoint is the URL you connect to; node access defines the underlying infrastructure (shared, dedicated, archive). The same endpoint can serve different access levels depending on your plan.

Q: Can I change my node access type later?

Yes, most RPC providers allow upgrading from shared to dedicated or adding archive access. Check with your provider for migration steps.

Q: Does node access affect transaction confirmation speed?

Indirectly. Dedicated nodes can have lower latency and faster block propagation, potentially reducing confirmation times. However, finality depends on the Solana network itself.

Q: How do I know which node access type my provider offers?

Review the provider’s documentation or contact support. For OnFinality, see our Solana RPC endpoint page and pricing for details.

Key Takeaways

• Node access in Solana RPC services determines request limits, supported methods, latency, and reliability.
• Shared access is for development and low traffic; dedicated access for production with consistent performance; archive for historical data.
• Evaluate your throughput, method needs, and latency requirements before choosing.
• Always test your critical RPC methods with the intended access type using simple curl or SDK calls.
• For production, consider dedicated nodes and plan for failover to ensure uptime.