Dedicated RPC nodes are blockchain endpoints reserved exclusively for one customer. Shared RPC nodes are pooled across many users. Production teams should upgrade from shared to dedicated when sustained throughput exceeds 30 requests per second, when tail-latency spikes start breaking time-sensitive operations, or when compliance requires isolated infrastructure.
Most dApps start on shared plans. Most teams stay on them too long. This guide is the decision framework for knowing when to move, what it actually costs, when to NOT bother upgrading.
We work with teams operating shared and dedicated infrastructure across 24 production networks. The triggers below are the ones that show up in real outage post-mortems, not vendor marketing.
What is a dedicated RPC node?
A dedicated RPC node is a blockchain endpoint where 100% of the underlying server capacity is reserved for a single customer. Unlike shared RPC nodes that pool requests from many customers across the same physical infrastructure, a dedicated node guarantees CPU, memory, network bandwidth, request throughput to one workload only. No noisy neighbors. No shared rate limits.
Dedicated nodes are sometimes called private nodes or bare-metal nodes. The terminology varies by provider but the core property is the same: isolated capacity reserved exclusively for one customer.
Shared vs dedicated RPC: the core difference
The core difference between shared and dedicated RPC nodes is resource isolation. Shared nodes split a pool of compute, memory, network capacity across many tenants with per-customer rate limits. Dedicated nodes assign the entire pool to one customer. This changes everything about how the endpoint behaves under load.
Side-by-side comparison
| Property | Shared RPC | Dedicated RPC |
|---|---|---|
| Resource isolation | Pool shared with other customers | Reserved exclusively for one customer |
| Rate limits | Per-customer caps | None (limited by hardware) |
| Latency | Variable, sensitive to neighbor traffic | Predictable, depends only on your workload |
| Cost structure | Per-request (often credit-weighted) | Fixed monthly plan priced in request units |
| Setup time | Minutes (API key issued) | Hours (node provisioned) |
| Best for | Sub-30 RPS workloads, MVPs, prototypes | Sustained high throughput, low-latency apps, compliance |
| Failure mode | Noisy neighbor degrades your p99 | None from neighbors, only your own load |
Shared works for the long tail of workloads. Dedicated wins for the head of the curve where performance predictability matters more than per-request economics.
The 4 signals you have outgrown shared RPC
Four signals reliably indicate that a workload has outgrown shared RPC: sustained throughput above 30 requests per second, p99 latency spikes above 500 milliseconds, repeated rate limit responses during normal operation, regulatory or audit requirements for isolated infrastructure. Hitting any one of these warrants the upgrade conversation. Hitting two means you should have moved already.
Signal 1: Sustained throughput above 30 RPS
Shared plans handle bursty workloads well. They struggle with sustained throughput. If your dApp consistently runs above 30 requests per second on a single chain, you are using a meaningful fraction of the shared pool’s capacity reserved for any one tenant.
Above 100 RPS sustained on a single chain, you are almost certainly the noisiest neighbor on your shared plan, which means you are also subsidizing other customers’ good experience while paying full per-request rates for your own.
Signal 2: Tail latency spikes above 500ms p99
Median latency on shared plans is fine. The problem is the tail. p99 latency that occasionally spikes to 1-2 seconds means another customer on your shared infrastructure is hammering it. If your dApp has time-sensitive operations (price feeds, liquidations, MEV-adjacent workflows), tail-latency spikes break the user experience even when median performance looks great.
Production teams running latency-sensitive workloads should target p99 under 500 milliseconds. If your shared plan cannot deliver that consistently, the infrastructure layer is the problem.
Signal 3: Rate limit responses during normal traffic
HTTP 429 responses or -32005 JSON-RPC errors during normal operation are the loudest signal. Shared plans enforce caps. When you start bumping into them regularly, you have two options: pay for a higher shared tier (which usually has its own caps) or move to dedicated where the only limit is hardware.
If you find yourself building elaborate retry-and-throttle logic to stay under your provider’s rate limit, the rate limit is the bottleneck. Remove the bottleneck.
Signal 4: Compliance or audit requirements
Some workloads require infrastructure isolation as a regulatory or contractual requirement. Financial protocols, institutional DeFi, KYC-gated platforms, regulated stablecoin issuers often need to demonstrate that customer data and request patterns do not co-mingle with other tenants. Shared plans cannot provide this.
Dedicated nodes satisfy isolation requirements by design. Combined with ISO 27001 certified infrastructure, dedicated capacity is often the only configuration that passes enterprise procurement review.
The cost crossover: when dedicated becomes cheaper than shared
Dedicated RPC becomes cheaper than shared at the point where your monthly request volume on a credit-weighted shared plan exceeds the flat fee of a dedicated node. For most teams running EVM workloads, this crossover happens between 30 million and 100 million requests per month depending on which methods dominate the workload.
The credit-weighted trap
Most shared RPC plans price by “compute units” with hidden per-method multipliers. Some methods are genuinely more expensive to serve, but credit-weighted plans amplify that asymmetry to extremes. On typical credit-weighted plans, eth_getLogs over a large block range can cost 75 times more than a simple eth_blockNumber query. debug_traceTransaction can cost 200x. The weights are often opaque until you read the invoice.
The trap: if your workload includes any of the expensive methods (eth_getLogs, trace_block, debug_traceTransaction, getProgramAccounts), your effective per-request cost can be 10-100x the headline price. Predicting your monthly bill becomes guesswork. A traffic spike during a token launch can produce a five-figure surprise overage.
Providers with published per-method weights in a tight band (for example reads = 3 RU, eth_getLogs = 4 RU, writes = 5 RU, debug_* = 6 RU) keep the variance bounded. Heavy methods still cost more than cheap ones, but 33% more instead of 7500% more. Combined with monthly RU buckets and no per-second throttling, your bill is forecastable before you ship.
Worked example: 50 million requests per month
Take a mid-size dApp doing 50 million requests per month across Ethereum. Mix of methods: 30% eth_call, 30% eth_getBalance, 20% eth_getBlockByNumber, 20% eth_getLogs.
On a credit-weighted shared plan with typical multipliers (reads = 1 unit, eth_getLogs = 75 units):
- Effective weighted units: 50M × (0.8 × 1) + 50M × (0.2 × 75) = 40M + 750M = 790M weighted units
- Cost at typical credit-weighted pricing: often $500 to $1,200 per month, hard to predict in advance
- Worst case during a market event: 2-3x spike in heavy methods produces overage you cannot cap
On a flat-monthly plan with published RU weights (BoltRPC Business tier):
- Effective RUs: 50M × (0.8 × 3) + 50M × (0.2 × 4) = 120M + 40M = 160M RUs
- Fits inside the Business tier 500M RU bucket at $699/mo monthly, $579/mo annual
- Cost: $699 (or $579 annual). Predictable. No method-weighting surprise. Headroom for traffic spikes.
The dedicated Enterprise tier on top adds isolated node capacity and custom SLA for workloads that need it. For most teams the flat-monthly Business tier already wins on predictability before isolation enters the conversation.
When the math favors shared credit-weighted plans
If your workload is under 10 million requests per month, uses only cheap methods, never spikes, credit-weighted shared plans can be cheaper than flat-monthly plans. The crossover starts mattering above 10M/month or whenever a single heavy method enters the mix.
When NOT to upgrade to dedicated
Most teams should not upgrade to dedicated RPC. Workloads under 30 sustained requests per second on a single chain, single-chain MVP apps, dApps where failover is the primary reliability concern, teams without operational maturity to consume the additional capacity efficiently all get more value from staying on shared infrastructure with multi-provider failover.
Sub-30 RPS workloads
If your peak is 30 RPS and your median is 5 RPS, dedicated capacity sits idle most of the day. You are paying for unused isolation. Shared is the right answer.
Single-chain MVPs
Pre-launch dApps and MVPs running on a single chain rarely justify dedicated. Variable traffic patterns, uncertain product-market fit, the need for fast iteration favor flexible shared plans that scale up or down without renegotiating contracts.
Failover-only redundancy
Dedicated nodes give you isolated capacity, not redundancy. A single dedicated node still goes down occasionally during maintenance or hardware faults. If reliability is the primary concern, multi-provider failover across two or three shared endpoints solves the problem at a fraction of the cost. See our RPC reliability guide for the failover pattern.
Teams without operational maturity
Dedicated capacity has to be used to be worth paying for. A team that does not measure their actual RPS, p99 latency, error rates is unlikely to use the dedicated capacity well. Build the monitoring discipline first, then upgrade. Otherwise you pay for capacity you cannot prove you need.
Does the chain change the decision? Shared vs dedicated by network
The shared vs dedicated thresholds shift by chain because block times, dominant methods, traffic profiles differ across networks. The 30 RPS trigger is a good default for Ethereum mainnet. On faster chains it arrives sooner, on long-tail chains it may never arrive at all.
High-throughput chains (Solana, BNB Chain, Base). Fast block times multiply polling volume: an app that polls every block does 5x the requests on a 2-second chain that it would on Ethereum. Heavy state queries (getProgramAccounts on Solana, eth_getLogs over busy BNB Chain ranges) push weighted costs up quickly, so the cost crossover lands earlier. Teams on these chains should measure sustained RPS within the first month of production traffic.
Ethereum mainnet and large EVM chains (Polygon, Avalanche, Arbitrum, Optimism). The default framework above applies as written. Indexing-heavy workloads dominated by eth_getLogs are the usual reason these teams cross to dedicated capacity ahead of their raw RPS number.
Long-tail EVM chains (Moonbeam, Moonriver, Scroll, X Layer). Traffic volumes on smaller networks rarely justify isolated hardware. Shared capacity with multi-provider failover is almost always the right answer. Consolidating these chains under one provider key keeps the vendor overhead near zero.
Chains outside our list (NEAR, TON, XRP Ledger, Cardano, Movement). The decision framework is universal: resource isolation economics work the same on every network, so the RPS, tail-latency, compliance triggers above still apply when you evaluate any provider’s dedicated offering on those chains. BoltRPC currently serves 20+ EVM and non-EVM networks through one API key: the full blockchain RPC endpoint list shows what is live today.
How dedicated RPC works on BoltRPC
BoltRPC dedicated capacity is included in the Enterprise tier. Dedicated nodes run on infrastructure operated by an ISO/IEC 27001:2022 certified team, support all 24 production networks through a single API key, use flat-monthly pricing with published per-method RU weights (no opaque credit multipliers), include a dedicated team member as part of the plan.
Tier comparison
| Plan | Monthly | Annual | Request units | Best for |
|---|---|---|---|---|
| Builder | $49/mo | $41/mo | 30M | Solo devs, MVPs |
| Pro | $199/mo | $165/mo | 150M | Production dApps under 30 RPS |
| Business | $699/mo | $579/mo | 500M | High-volume workloads, custom key management |
| Enterprise | Custom | Custom | Custom | Dedicated nodes, custom SLA, ISO 27001 certified team |
The Enterprise tier is the dedicated tier. Custom request unit allocations, dedicated blockchain nodes, custom SLA, account team support. The annual billing cycle saves 17% on all standard tiers. See the pricing page for the full feature breakdown.
Multi-chain on a single API key
Most dedicated node providers price per chain. Running dedicated capacity across 5 chains means 5 separate contracts, 5 separate API keys, 5 different SLAs. BoltRPC consolidates dedicated capacity across all 24 supported networks under one API key. One contract. One billing relationship. One support channel.
For teams operating across EVM and non-EVM chains, this is the difference between a sprawling vendor management problem one consolidated infrastructure layer.
FAQ
How much does a dedicated RPC node cost?
Dedicated RPC pricing is workload-specific because dedicated capacity reserves hardware, not just a quota. BoltRPC dedicated nodes are part of the Enterprise tier with custom pricing sized to your traffic profile, chain coverage, SLA requirements. Email the BoltRPC team for a quote tailored to your workload. Single-chain dedicated capacity from major providers in the market generally ranges low hundreds to low thousands of dollars per month.
Is dedicated RPC the same as a private node?
Effectively yes. The terminology varies: “dedicated node”, “private node”, “bare-metal node” usually refer to the same thing: a blockchain endpoint where the underlying server capacity is reserved for one customer. Some providers use “private” to mean a logically isolated tenant on shared hardware, which is different. Confirm with the provider whether you get physical isolation or only logical isolation.
Can I get a dedicated node for any chain?
Most major chains are available as dedicated nodes from major providers. BoltRPC offers dedicated capacity across all 24 supported production networks including Ethereum, Solana, Arbitrum, Linea, Starknet, Base, BNB Chain, Avalanche, Optimism, zkSync, Polygon. Testnet support is available on the same API key. Less-supported chains may require custom arrangements.
Do I need a dedicated node for a trading bot?
Most trading bots do not need dedicated nodes for their RPC layer. Multi-provider failover across two or three high-quality shared endpoints typically delivers better latency consistency than a single dedicated node. The exception is high-frequency strategies where every millisecond matters. In those cases, co-located dedicated infrastructure with direct chain access becomes justifiable.
How long does setup take?
Shared RPC access is instant: sign up, get an API key, start sending requests. Dedicated node provisioning takes longer because actual server capacity gets allocated. Typical setup time is 4-24 hours for major chains, longer for chains requiring custom configurations. Plan dedicated upgrades around the lead time, not as an emergency reaction to an outage.
The decision in one paragraph
Stay on shared if your workload is under 30 RPS, your peak traffic is bursty, your primary reliability concern is failover not isolation. Move to dedicated if you have sustained throughput, latency-sensitive operations, compliance requirements, request volumes above 30 million per month with credit-weighted billing eating your margin. The number that matters is your actual RPS profile measured over 7 days, not your peak. Measure first, decide second.
Try dedicated capacity without commitment
BoltRPC offers a free 2-week trial covering Enterprise-tier dedicated capacity. Start the trial at trial.boltrpc.io. If your workload profile fits the dedicated triggers above, the trial will show it within the first 7 days of running real traffic.
