Every Solana application talks to the chain through an RPC node. Reading a balance, sending a swap, watching a program for new accounts: all of it is a request to a server that replays the ledger and answers questions about it. Most teams never think about that server, and for a long time they don’t need to.
Shared RPC plans are the right place to start. They cost little or nothing, take a minute to set up, and handle the traffic of most early projects without complaint. The trouble is that the point where they stop fitting rarely arrives as a clear failure. It shows up as a slow drift: a few more timeouts, a bill that’s harder to predict, a bot that lands fewer transactions than it did last month.
This piece is about recognizing that point, understanding what Solana dedicated nodes do and do not fix, and asking the right questions before you sign up for one.
Five signs you have outgrown shared RPC
- HTTP 429 during normal traffic. Rate limits are expected during a spike. If you hit them on an ordinary Tuesday, your baseline load has grown past the plan, and every retry adds latency your users feel.
- Latency you can’t explain from your own code. On a shared pool, other customers’ traffic competes with yours for the same CPU, disks and network. If your p99 latency moves while your own request volume stays flat, you are probably seeing your neighbors.
- Account scans are slow or expensive. Calls such as getProgramAccounts and token account lookups by owner or mint scan large parts of the account set. Shared providers often rate-limit them hard or charge many times the cost of a normal call. DEX frontends, portfolio trackers and holder analytics lean on exactly these methods.
- You poll for changes a stream would push to you. If your indexer or bot asks the same question every few hundred milliseconds, you are spending your quota to learn that nothing happened. Streaming with Yellowstone gRPC, a Geyser plugin that pushes accounts, transactions and slots with server-side filters, is the better tool, and it is often missing or limited on shared plans.
- The bill depends on what your code did this month. Credit-based pricing is fair for light, uneven usage. For a bot or indexer that runs around the clock, it turns every new feature into a cost forecast. A fixed monthly price per machine is easier to plan around once your load is steady.
One of these on its own is usually fixable with caching, batching or a bigger shared plan. Two or three together, sustained over weeks, is the signal to look at dedicated hardware.
What a dedicated Solana node changes
A dedicated node is a single-tenant server running the validator client in RPC mode for one customer. It is not a voting validator: it holds no stake and earns no rewards. Its only job is to serve your requests.
The practical differences:
- Capacity is bounded by hardware, not a meter. There is no plan-level requests-per-second cap. Light calls such as getAccountInfo and getLatestBlockhash are cheap, and a well-specified bare-metal machine serves thousands per second.
- Nobody else’s traffic touches your machine. Tail latency becomes a function of your own load and your network distance to the node.
- You can turn on what shared plans restrict. Account indexes by program ID, mint and owner make account scans fast. gRPC streaming replaces polling. An IP allowlist limits the endpoint to your own servers, which matters because the RPC service in Agave, the most widely used validator client, is not designed to be exposed to the open internet.
What it does not change
Dedicated hardware is not a latency cheat code. Network distance still applies: a node in the wrong region is slower for sends than a shared endpoint in the right one. Transactions still need confirming. And the hardware is serious. Anza’s published requirements for an RPC node start at 16 cores and 256GB of RAM, and 512GB once account indexes are enabled, with separate NVMe disks for accounts and ledger. Cheap or virtualized hardware shows up as a node that falls behind the chain after a restart.
If you have a single bursty workload, a larger shared plan is often the better deal. Dedicated pays off when load is steady and heavy, or when you need features a shared pool can’t give you.
Questions to ask before you buy
Dedicated node offers look alike on a pricing page and differ a lot underneath. These questions separate them quickly:
- Is it bare metal or a VM? Bare metal gives the node direct NVMe access and no hypervisor, which shows up in tail latency and catch-up time more than in averages.
- What exactly is in the box? Ask for the CPU model, RAM and disk layout. Higher clock speed matters more than core count for Solana, and accounts and ledger should sit on separate disks.
- Does everything run on your node? Some offers stream gRPC from dedicated hardware but serve JSON-RPC, sends or archival queries from a shared pool. That can be fine, but you should know which requests leave your machine.
- Are account indexes available? If you call getProgramAccounts or list token accounts by owner or mint, you need them, and they need extra RAM.
- Which regions, and can you test from yours? For trading, the node should sit near the validators you send to. For reads, it should sit near your application servers. Measure from where your code runs before committing.
- How do you manage access? Look for an IP allowlist you can change yourself without a support ticket.
- What happens during a restart? With two or more nodes, a load balancer with health checks keeps you serving. Ask whether one is included.
- What are the commitment terms? Check deployment time, uptime terms, and whether monthly plans can be cancelled before the next cycle.
The short version
Start on shared RPC and stay there as long as it serves you. Watch for sustained rate limiting, latency you can’t trace to your own code, slow account scans, constant polling and bills that track your feature list. When several of those appear together, a dedicated node trades a metered, noisy environment for a fixed price and hardware you control.
Before you switch, measure. Run your real method mix against a trial node from the region your code lives in, and compare p50 and p99 latency with what you have today. The numbers will tell you whether the move is worth it far better than any pricing page.
About the author: The team at Solana Tracker runs RPC and data infrastructure for Solana traders and developers, and sells dedicated nodes. For a longer comparison of hardware, features and published provider pricing, see their Solana Dedicated Nodes.