Hidden Costs of Bad Blockchain Infrastructure (+ 4 Performance Benchmarks to Evaluate Any RPC Provider)

True cost of bad blockchain infrastrucutre by GetBlock CTO Nikita Iugov

Written by Nikita Iugov, CTO at GetBlock. Based on the joint webinar with Simplify Labs, March 10, 2026. The full recording is available on YouTube.

Blockchain node infrastructure rarely gets attention until something breaks. By then, the cost is already paid – in downtime, lost clients, engineering hours spent firefighting.

Earlier this month, I joined Kareem Abdelrakhman, CEO of Simplify Labs – one of our longest-standing partners – for a live webinar on the true cost of bad infrastructure. We explored why infrastructure decisions that seem purely technical turn out to have serious business consequences.

Simplify Labs switched from self-hosted nodes to GetBlock over a year ago. Between their experience and our expertise of running RPC infrastructure, we had a lot to cover:

Real tradeoffs between self-hosting and managed nodes
The four metrics that tell you whether your RPC setup is healthy or RPC provider is good (including one that's almost never talked about)
Why Simplify Labs moved from self-hosted nodes to using a managed RPC
How infrastructure strategy can evolve as your business scales

Let’s go through it piece by piece.

What is a blockchain node, and why do you need one?

A blockchain is also software that needs to be run somewhere. If you're building a decentralized application, if you're a trader, or if you work with on-chain analytics – you need to interact with raw blockchain data: blocks, transactions, everything that represents the current state of the network. Your application needs to read that data, send transactions, respond to on-chain events. A node is what gives you that connection.

Hosting a blockchain node is fundamentally the same problem as hosting any application – you need somewhere to run it. And this is one of the most consequential infrastructure decisions.

How do you actually run blockchain infrastructure?

If you ask me how to approach this, I see two real options.

1. Self-hosting

You can run the node yourself, either on bare metal servers or on cloud virtual machines. Here, you're responsible for the setup, configuration, and knowing what you're doing.

If you go this route, everything you need is open source – node client software, documentation and configuration guides. And if you get stuck, the Web3 community is genuinely helpful – post a question in the right Discord channel or GitHub, and you'll get a real answer.

That said, running nodes reliably at production scale takes deep expertise and time to build. You have to pass through a lot of failures to gain the knowledge of how to do it properly, what parameters to set, how to recover when something breaks.

For large businesses with stable infrastructure needs and a mature DevOps team, there's a case for it. For everyone else, I'm skeptical it's the right use of resources.

2. Outsourcing the node operation to infrastructure providers

A dedicated RPC provider runs the nodes on your behalf and gives you API access. You don't manage the underlying infrastructure at all. The provider handles uptime, performance, and scaling. You pay for access.

This is what GetBlock does. And the expertise that comes from running nodes at scale – across dozens of chains, thousands of edge cases over six years – is genuinely hard to build from scratch internally.

For most teams, this is the right starting point. Not because self-hosting is technically impossible, but because of what it actually costs when you count everything. And that's exactly what I want to get into next.

The four core metrics every infra lead should care about

If you're measuring the health of your blockchain setup and especially if you’re evaluating blockchain infrastructure providers right now, here's what I'd tell you to look at:

Uptime (stability)
Response time (speed and latency)
Scalability (throughput, RPS, burst handling)
Node headlag

For each one it's worth understanding not only what it means technically, but what actually happens to your product or business when it goes wrong.

1. Uptime

Uptime is the percentage of time the service is available.

AWS advertises 99.99% uptime, which translates to roughly 10 minutes of allowed downtime per month. GetBlock's SLA commitment is 99.95+%.

Why is it so critical? If your RPC node is down, your application cannot interact with the blockchain at all.

For a decentralized application, this means complete downtime – the app's state lives on-chain, and without node access there's nothing to show the user.
For a centralized exchange, for example, it means deposits and withdrawals stop processing.

There's no graceful degradation; the dependency is binary.

The good news is that uptime is a public metric. Providers publish status pages. Go look at them, compare them.

2. Response time

Response time measures how quickly requests reach the server and return the result. To build a responsive application, you guessed it, response times should be as low as possible.

This affects both user experience and backend performance.

On the user-facing side: nobody wants to press "deposit" and wait more than five seconds. Users in crypto are accustomed to fast feedback.
On the technical side: response time compounds. If you're running a data indexing pipeline that makes thousands of RPC calls, even a small increase in average response time adds up to meaningful data inconsistency.
For trading systems the stakes are higher: in competitive on-chain environments, traders are often racing for position within the same block, where the difference between a successful and failed transaction is measured in milliseconds.

Response time isn't always published by providers because it varies based on the method called, the chain, and the client's geographic location. Testing under your own load profile from your own infrastructure gives you much more useful data.

One practical shortcut: independent platforms like CompareNodes publish real-time performance rankings across providers, chains, and regions – worth checking as a starting reference point. If you go there and look at Solana or BSC response times, for example, you'll find GetBlock consistently ranking among the fastest.

3. Scalability

Scalability describes how the service behaves as request volume increases and how it handles spikes. In Web3, traffic is heavily event-driven – a token launch, a market move, a protocol announcement can multiply traffic overnight.

I think about the MELANIA and TRUMP token launches in early 2025. Solana infrastructure effectively seized up across the ecosystem, including at platforms like Jupiter that had invested seriously in scalability preparation. The hype-driven demand simply exceeded what anyone had planned for.

Notably, users don't get a partial service in this case – some get responses, others get errors. That's an awful experience to deliver, especially for a financial product where inconsistency reads as unreliability.

When evaluating a provider, ask specifically about rate limits and burst handling. For applications with unpredictable or rapidly growing traffic, dedicated node services are worth considering.

4. Node headlag

Node headlag is the most Web3-specific metric on this list and the one most frequently overlooked.

A blockchain node is a live replica of a network that's constantly producing new blocks – Ethereum roughly every 12 seconds, Solana much faster. To serve accurate data, a node needs to stay synchronized with the network's current state.

When a node falls behind (due to hardware performance issues, network problems, or software bugs) it starts serving stale data. The network may be at block 1,001 while the lagging node is still at block 990.

For users, this shows up as:

a transaction that’s confirmed on-chain but doesn’t appear in the app
a balance that is out of date
an action that looks like it succeeded in the UI but later fails

These are confusing, trust-destroying experiences, especially when real money is involved.

From the engineering side, headlag incidents are also difficult to diagnose: by the time a developer investigates a support ticket, the node has usually caught up, and everything looks normal. The problem is real but leaves no trace.

How to actually track these metrics

Not all of these metrics are published by RPC providers, and that's not because they're hiding something. Response time, scalability, and node headlag all depend heavily on your specific load profile. There's no universal benchmark that means much out of context.

My recommendation: build internal monitoring and measure these yourself. Most good providers will also be able to answer direct questions about how they monitor and manage performance internally.

The Simplify Labs case

The most useful part of this webinar was Kareem walking through what these choices actually looked like for Simplify Labs – a fintech and Web3 software development company that tried the self-hosted path before switching to GetBlock.

Simplify Labs works with businesses who in turn serve end users. So their infrastructure decisions ripple outward: their uptime affects their clients' uptime, which affects their clients' users. That dependency chain makes the stakes concrete.

For a period, they ran self-hosted nodes. Kareem confirmed specific pain points drove the decision to switch:

Unpredictable ETAs: Adding a new chain could take weeks between research, deployment, tuning, and stabilization. This made it hard to give clear timelines to customers.
Hidden infra costs: When they finally put everything “on paper” (AWS bills + DevOps and developer time + incident handling), running their own nodes turned out to be more expensive than using a specialized provider.

All of this pushed them to re-evaluate and migrate to GetBlock as a managed RPC provider. The main drivers:

Predictable economics: With GetBlock, they know the price of RPC upfront and compare it to internal costs
Faster time to market: Instead of spending weeks deploying a new blockchain, they can come to GetBlock, ask for the chain or use an already supported one, and give their own customers concrete ETAs
Focus on core business: Their team could stop context-switching between “inside” (keeping nodes alive) and “outside” (winning and serving clients). They shifted focus to product, customer acquisition, and growth

When you actually put on paper the real cost of the infrastructure — including your employees maintaining or deploying new nodes, the infrastructure itself like AWS — and you calculate all of it... you look on the market and you see GetBlock, you're like, 'what have I been doing for these years? I could save a lot of money.'

Kareem Abdelrakhman, CEO at Simplify Labs

Practically speaking, Simplify Labs didn’t throw away self-hosting entirely – they moved day-to-day traffic to a managed RPC and kept a couple of heavy-use nodes as self-hosted backups. That hybrid gave them the speed and predictability of managed infra, plus the safety net for critical chains.

On hybrid infrastructure & when it makes sense to self-host

One question came up from the audience that I think is worth addressing here: as your business scales, does it make sense to bring infrastructure back in-house?

My honest answer: in some cases, yes. When you have a mature business, the conversation shifts to efficiency. If you're running very high volumes on specific chains and you have a strong internal team, there are cases where self-hosting nodes can reduce costs or give you more reliability.

But the moment you move everything back in-house, you're putting all eggs in one basket. And if something goes wrong with that basket, there's no fallback.

What most experienced teams in this space have landed on is a hybrid model.

A managed provider as your primary, self-host as backup
Self-host as your primary, provider is your backup
Use a managed provider as your primary, keep a second provider as backup

Yes, running two providers or combining them with self-hosting may cost more on paper. But as Kareem put it: "It's still cheaper than maintaining your own node when you put the equivalent of the salary into the time and the potential loss of your volumes when your clients are facing those downtimes."

Diversifying risks of downtime is the best strategy.

Wrapping up

Infrastructure is the foundation of your product. I think about it like building a house. You need a solid foundation first. Without it, nothing built on top will be reliable. But a good builder doesn't manufacture bricks from scratch.

The good news is that the barrier to getting the foundation right has never been lower. The managed blockchain infrastructure market is mature, competitive, and well-priced relative to what it would cost to build and maintain internally. The case for starting there is strong.

Check GetBlock services designed for flexible growth. We work closely with customers on non-standard setups. If that sounds like you, let's talk.

Let specialists handle the infrastructure, and use that saved time on the thing that actually differentiates your product.

Let's build reliably,

Nikita Iugov, CTO at GetBlock

nikita.i@getblock.io

https://github.com/NikitosnikN