Dedicated Node vs Shared RPC: When You Actually Need One

"Dedicated node" is one of the most common things people search for when their RPC starts misbehaving. Usually the real question underneath is: my shared endpoint is rate-limiting me, returning inconsistent answers, or missing a method — do I need my own node?

Sometimes the answer is yes. More often it is "not yet", and the fix costs a fraction of a dedicated node. This post covers what each option actually is, what dedicated nodes cost in 2026 according to the providers' own pages, and the concrete signals that tell you which one you need.

What you are buying in each case

A shared endpoint is a URL in front of a pool of nodes that many customers use. The provider load-balances your requests across that pool, and your plan buys a rate limit (requests per second) and sometimes a monthly volume, not a machine. SwiftNodes is a shared-endpoint provider: every plan is a rate limit across all 86 chains we serve, from 2 requests per second on the free tier to 500 on Pro.

A dedicated node is a node, or a small cluster, that serves only you. You buy the machine's capacity. There is no per-request limit beyond what the hardware can do, and you usually get a say in the configuration: archive or full, which client, which tracing flags, which region.

The difference that matters most is not speed. It is consistency. A shared endpoint gives you whichever healthy node answers. A dedicated node always gives you the same one.

What a shared pool looks like from the client side

This is easy to state and hard to picture, so here is a measurement from our own endpoint. On 2026-09-23 I sent the same kinds of requests to our Cronos endpoint and got two different answers depending on which upstream node served them:

Both nodes were healthy. They were simply configured differently, and a pooled endpoint exposes the union of their quirks. For most applications this is invisible: you read the head, send transactions, and query recent logs. For an indexer backfilling months of history, it is the difference between a job that finishes and one that fails every few thousand requests on whichever node has the tighter limit.

The shared-endpoint fix is to code to the strictest node: chunk eth_getLogs at the smaller cap, and assume the shallower history. That is what our Cronos guide recommends. The dedicated-node fix is to own the configuration.

What dedicated nodes cost in 2026

Pricing for dedicated infrastructure is mostly not public. What the providers themselves publish, as of September 2026:

So a dedicated Ethereum node lands at roughly $1,000–1,300 a month where a price is published, and more when you need archive or several regions. Compare that with shared flat-rate plans, which run from $49 to a few hundred dollars a month. On SwiftNodes, Pro is $249/mo for 500 requests per second on every chain.

That gap is the whole decision. A dedicated node needs to fix a problem worth about $1,000 a month to you.

Four signals that you actually need one

1. You need a method or configuration the shared pool does not offer. Examples: debug_traceTransaction on a chain where the pool has no tracing nodes (our Cronos endpoint returns -32601 for the whole debug_ namespace), full archive state on a chain where the shared nodes prune (Cronos keeps about 100 blocks of state), or a specific client for its custom namespace. Check the provider's method support first. Ours is on the measured method matrix. If the method is not there on any shared plan, a dedicated node is the honest answer.

2. Your sustained load is above the top shared plan. Look at your sustained requests per second, not your peak. If you consistently need several hundred requests per second on one chain, the per-request economics favour your own capacity. Bursts are cheaper to absorb with batching and retries — see JSON-RPC batching and RPC rate limits.

3. You need every response to come from the same node. Backfilling indexers, reconciliation jobs and anything that compares state across consecutive calls suffer when consecutive requests can land on nodes a block apart, or with different pruning. You can engineer around it (pin block numbers in every call, use the smallest shared limits), but past a certain volume a single node is simpler.

4. Compliance or data locality says so. Some teams must know exactly which machine in which jurisdiction served a request. A shared pool cannot promise that. A dedicated node in a named region can.

If none of these apply, you probably do not need a dedicated node yet.

Signals that look like "I need dedicated" but are not

429 errors on a free or public endpoint. That is a rate limit, not a capacity problem. Past 2 requests per second, our free tier answers {"error":"Rate limited","limit":2,"plan":"Free"}. A paid shared plan moves that limit from 2 to 50–500 requests per second for $49–249 a month. See public RPC vs paid RPC.

Occasional stale or lagging responses. Usually one lagging node in a pool the provider should be ejecting. Our health checker compares every upstream's height with the chain's best and stops routing to one that trails by more than 50 blocks (EVM) for two consecutive rounds. Is your RPC node synced? covers how to detect it from the client side.

"My eth_getLogs calls fail." Almost always a range cap. Chunk the range; a dedicated node would have a cap too, just one you set yourself. See eth_getLogs range caps.

Latency. A dedicated node in the wrong region is slower than a shared pool with a node near you. Measure p95 from where your code actually runs before paying for isolation.

The middle option: run your own node

If you need consistency and configuration control but not a vendor-managed machine, running a node yourself is the third choice. The hardware is often cheaper than a managed dedicated node. The operations work (upgrades, disk growth, resyncs, monitoring) is not. We did the full cost comparison in self-hosted node vs RPC provider, and the Ethereum archive numbers are in Ethereum archive node cost.

A common pattern that works well: shared endpoint for everything, plus one self-run or dedicated node for the single job that needs consistency (usually the indexer backfill). You pay dedicated prices for one chain and one workload, not for your whole stack.

The short version

A dedicated node buys you consistency and configuration control, not raw speed. Published 2026 prices put a dedicated Ethereum node at roughly $1,000–1,300 a month (GetBlock from $1,000, Chainstack ~$1,279; QuickNode and others quote privately). Shared flat-rate plans cost $49–249 a month. You need dedicated when a method or history depth is missing from every shared plan, when sustained load exceeds the top shared tier, when consecutive calls must hit the same node, or when compliance requires a named machine. Rate limits, stale nodes, eth_getLogs errors and latency are usually fixed more cheaply without one.

If a shared endpoint covers your case, SwiftNodes serves 86 chains on one key with flat monthly pricing and a free tier at 2 requests per second, enough to test your workload before you decide anything. Get an API key.