Educational

Fixing slow Web3 apps: Why indexing is key to performance

Why is my Web3 app slow? It’s rarely the chain itself. The real bottleneck is the read path: from RPC ingestion to indexing and querying. Without real-time indexing, balances lag, trades disappear, and queries stall under load. A fast chain doesn’t guarantee a fast app, but a fast indexer does.

Wen-Chiao

03 Sep 2025 • 4 min read

When a dApp feels slow, most teams assume “the chain” or the app is to blame. In reality, those are rarely the bottleneck. The real bottleneck is the read path, the path between the raw chain data and your dApp. This path includes reading raw data from the chain, decoding it, indexing it for efficient retrieval, and then querying from the application.

As block times shorten and traffic grows, this read path becomes the speed limit for your application.

Think of the pipeline in four stages:

RPC ingestion: pull raw blocks, receipts, and logs.
Indexing: transform raw data into structured entities (swaps, positions, votes).
Querying: serve those entities through GraphQL, REST, or SQL.

If any stages have problems, your app will feel slow or unresponsive. A fast chain does not guarantee a fast app, but a fast indexer does.

Why indexing defines the speed limit

Blockchains behave like OLTP systems: great at writes, terrible at reads. dApps need OLAP-style queries: joins, filters, and aggregations across time.

Indexing is the bridge that converts append-only blocks into app-ready answers.

Three realities as chains get faster:

Freshness equals trust. If your indexer lags by even a few blocks, a user swaps and still sees the “old” balance. That’s a data problem.
Traffic spikes will become the norm. Token launches, liquidations, and on-chain games demand sustained and burst RPS without throttling.
Protocols are complicated. Human-interpretable data can come from many places, including off-chain sources, and complex computations may be needed before presentation.

Why indexing must be end-to-end

It’s not enough to have a “fast indexer.” To truly stay fresh and fast, a provider must oversee an entire optimized stack:

Top-tier RPC nodes with failover: Poor RPC nodes can not only mean slow data, but also corrupt and missing data. And even the best-maintained RPC nodes can fail. A robust RPC infrastructure requires error detection and failover.
Indexing logic: Efficient, deterministic transformations turn logs and traces into structured entities indexed for fast and easy retrieval.
Querying layer: GraphQL, REST, or SQL endpoints must deliver sub-second responses at thousands of RPS, even during peak events.

If a provider only manages one stage, say, indexing without RPC redundancy, the entire pipeline is at risk of failure. End-to-end control is what separates enterprise data platforms from discount data vendors.

How a slow data pipeline reveals itself

Balances and positions don’t update after user actions.
Data tables have missing entries during volatility.
Queries slow down under load.
Backfills take days when they should only take hours.

These aren’t “chain speed” issues but rather the result of underperforming data infrastructure.

❓ What is blockchain indexing: Part 1

What is true real-time blockchain data

Evaluate indexing providers on these end-to-end metrics:

Head lag: distance from chain head in blocks/ms.
P99 query latency: target <100 ms.
Sustained & burst RPS: 1,000+ sustained, bursts to 4,000 RPS at sub-second latency.
Backfill speed: reindex data that takes weeks in hours.
Reorg correctness: zero stale reads during forks.
Freshness SLO: % of queries served within X blocks of head.

Tips for getting ready on fast chains and growing mainstream adoption

As workloads grow, apps need infra that’s designed for scale:

Use subgraphs for protocol-level data.
Stream live, backfill in parallel to stay fresh while supporting analytics.
Reorg-safe writes prevent corrupted state and problematic entries.
Global infra keeps data sources close to users.
Cache indexed results tied to finality windows.
Separate hot reads (UI) from cold queries (analytics, history).

Where Ormi fits in

At Ormi, we provide an end-to-end infrastructure managed internally with a hybrid cloud infrastructure to serve high-throughput applications.

RPC redundancy built in with automatic failover to avoid stale or missing blocks.
Real-time subgraphs with sub-30ms latency at 1,000+ RPS (bursts to 4,000).
Reorg-safe ingestion that stays at the chain tip.
70+ chains supported with a unified query layer.
GraphQL, REST, and SQL in one stack serving AI agents, analytics, and DeFi without switching providers.

For high-TPS networks and mainstream adoption, indexing must be end-to-end. That’s how your app feels instant, reliable, and trustworthy, even at scale.

Learn more about How to choose the right Web3 data indexer

The takeaway

A good UI gets attention, but an optimized end-to-end data infrastructure is what builds trust.

As chains accelerate and traffic surges, your Web3 app speed is no longer limited by the chain. It will be limited by how well your provider manages the entire read path, from RPC to queries. Pick an infra provider who owns the stack, cares about freshness, and scales under load. That’s the difference between an app that feels fast and one that feels broken.

About Ormi

Ormi is the next-generation data layer for Web3, purpose-built for real-time, high-throughput applications like DeFi, gaming, wallets, and on-chain infrastructure. Its hybrid architecture ensures sub-30ms latency and up to 4,000 RPS for live subgraph indexing, sub-10ms responses across 100+ API schemas, and a powerful SQL engine for historical and AI-ready data.

With 99.9% uptime and deployments across ecosystems representing $50B+ in TVL and $100B+ in annual transaction volume, Ormi is trusted to power the most demanding production environments without throttling or delay.