When You Need a Dedicated Solana Node
TL;DR
- - Shared nodes are fine for most applications — dedicated nodes are for high throughput or low latency
- - Dedicated nodes give you no rate limits, consistent latency, and customization
- - Monthly cost: $500–$5,000+ vs. $0–$200 for shared plans
A shared RPC node serves requests from many customers on the same hardware. A dedicated node is reserved for your exclusive use. The choice depends on your throughput requirements, latency sensitivity, and budget.
Shared vs. dedicated comparison
| Feature | Shared RPC | Dedicated RPC |
|---|---|---|
| Rate limits | 10–1000 RPS | Hardware-limited (10K+ RPS) |
| Latency consistency | Variable (noisy neighbors) | Consistent |
| Heavy methods (GPA) | Often restricted | Full access |
| Custom configuration | No | Yes (Geyser plugins, retention) |
| SLA | Best-effort or basic | Typically 99.9%+ |
| Monthly cost | $0–$200 | $500–$5,000+ |
When shared is enough
Most applications work well on shared RPC:
- Standard dApps with moderate transaction volume (< 50 TPS).
- Read-heavy applications that cache responses effectively.
- Development and testing — shared endpoints are ideal.
- Personal projects and prototypes.
- Applications that tolerate occasional 429 errors and implement retry logic.
When you need dedicated
Upgrade to dedicated when:
1. Rate limits block your application
You consistently hit 429 errors and cannot reduce call volume through batching, caching, or WebSocket subscriptions. A dedicated node removes the rate limit bottleneck.
2. Latency consistency matters
Shared nodes have variable response times because other tenants’ expensive queries (getProgramAccounts, getBlock with full data) affect your lighter queries. Trading bots, liquidation bots, and real-time applications need consistent sub-50ms responses.
3. You need heavy RPC methods
getProgramAccounts, getBlock with full transaction data, and other scan-heavy methods are often restricted on shared plans. A dedicated node has no such restrictions.
4. You need Geyser gRPC
Geyser plugins (Yellowstone gRPC) stream real-time account updates and transactions. They require access to the validator’s internal data pipeline, which shared nodes do not expose.
5. You need custom data retention
Standard nodes retain ~2 epochs. If you need longer history without using an external archive service, a dedicated node can be configured with extended retention or Bigtable backing.
6. Compliance or isolation requirements
Some applications (institutional trading, custodial services) require dedicated infrastructure for compliance, auditing, or data isolation.
Dedicated node types
| Type | Description | Use case |
|---|---|---|
| Managed dedicated | Provider runs the node, you get exclusive access | Most teams |
| Self-hosted | You run the hardware and software | Full control |
| Bare metal | You own/lease the physical server | Maximum performance |
| Cloud VM | Dedicated VM with SSD storage | Flexibility |
Managed dedicated
The provider handles:
- Software updates (Agave/Firedancer versions).
- Hardware maintenance and monitoring.
- Network configuration and peering.
- Geyser plugin setup and maintenance.
You get an RPC endpoint (and optionally Geyser gRPC) with no rate limits and consistent performance.
Self-hosted
You handle everything. This makes sense when:
- You need maximum control over configuration.
- You have operations experience with Solana validators.
- You want to avoid ongoing provider costs (but hardware costs remain).
Cost breakdown
Managed dedicated (typical ranges as of 2026-10-21)
| Tier | Specs | Monthly cost |
|---|---|---|
| Entry dedicated | 16 cores, 256 GB RAM, NVMe | $500–$1,000 |
| Mid dedicated | 32 cores, 512 GB RAM, NVMe | $1,000–$2,500 |
| High-performance | 64+ cores, 1 TB RAM, NVMe RAID | $2,500–$5,000+ |
| + Geyser gRPC | Add-on | +$200–$1,000 |
| + Archive (Bigtable) | Add-on | +$500–$2,000 |
Self-hosted hardware
| Component | Specification | Cost |
|---|---|---|
| CPU | AMD EPYC 7443P or similar (24+ cores) | $2,000–$5,000 |
| RAM | 512 GB DDR4 ECC | $1,500–$3,000 |
| Storage | 2x 4TB NVMe (RAID 1) | $1,000–$2,000 |
| Colocation | Rack space + bandwidth | $200–$800/month |
Migration checklist
When moving from shared to dedicated:
- Benchmark current usage: measure RPS, response times, and error rates on shared.
- Size the node: match specs to your actual workload, not theoretical maximum.
- Plan the cutover: update connection strings, test against the new endpoint, keep the shared endpoint as fallback.
- Monitor after migration: compare metrics to validate the improvement.
- Update retry logic: with no rate limits, retry behavior may need tuning.
FAQ
Can I use both shared and dedicated? Yes. A common pattern is dedicated for time-sensitive operations (sendTransaction) and shared for read-heavy, latency-tolerant operations (getAccountInfo with caching).
How long does it take to provision a dedicated node? Managed providers typically provision in 1–24 hours. Self-hosted requires days to weeks for hardware procurement and setup, plus hours for the node to sync with the network.
Will a dedicated node guarantee my transactions land? A dedicated node removes RPC-side bottlenecks (rate limits, latency variability). Transaction landing also depends on priority fees, network congestion, and whether you use staked connections. A dedicated node is one layer of the solution.
Can I downgrade back to shared? Yes. The RPC API is identical. Update your connection string and adjust your code for rate limits.
Sources
Updated: