What is blockchain indexing?

Updated August 2026

Blockchain indexing is the process of extracting data from a blockchain and reorganising it so that applications can query it efficiently. A blockchain stores transactions in sequential blocks optimised for consensus, not for questions like "show me every swap this wallet made last month" — indexing bridges that gap.

Without an index, answering that question means reading every block and filtering, which is impractical for any chain of meaningful size.

Why can't I just query the blockchain directly?

Because a blockchain is a ledger, not a database. Data is stored in the order it happened, and nodes expose it through JSON-RPC — an interface designed for asking about a specific block or transaction, not for searching across history.

Ask a node for one transaction and it responds quickly. Ask it for every transaction matching a pattern across five years of blocks and you are making millions of sequential requests. There is no index to help it, because indexes are not what a consensus system is built to provide.

What does an indexer actually do?

Three things:

Extract — read raw data out of the chain, either by querying a node or by capturing data as blocks execute.

Transform — decode it. Raw blockchain data is binary; turning it into "a Transfer of 500 USDC from address A to address B" requires knowing the contract's interface and applying it.

Load — write the result somewhere queryable: a Postgres table, a ClickHouse cluster, a GraphQL API, a stream your application consumes.

That pattern is why blockchain indexing is often described as blockchain ETL.

What makes it harder than normal ETL?

Three things ordinary data pipelines do not deal with:

History is enormous and you usually need all of it. Backfilling years of blocks sequentially can take days or weeks, and most applications need both complete history and live data.

The chain can reorganise. Recent blocks can be replaced. An indexer that treats them as final will silently hold wrong data. Handling reorgs correctly is a defining requirement.

Meaning is not in the data. A transaction is bytes. Decoding it requires the contract ABI or program IDL, and some of what matters — internal transactions, state changes — is not emitted as events at all.

What are the options?

Approach	What you get	Trade-off
Direct RPC	Simple, no extra infrastructure	Slow, unsuitable for historical queries
Hosted data API	Fast start, no operations	Fixed schema, limited to what the vendor exposes
Subgraph	GraphQL API, well-established	Sequential sync, EVM-oriented
Streaming engine	Full history and real-time, any sink	More architectural choice up front

Substreams is the last category: it processes history in parallel and keeps streaming at the chain head, sending output wherever you need it.

Frequently asked questions

Is indexing the same as running a node? No. A node participates in the network and stores chain state. An indexer reads that data and reorganises it for querying. You can index without operating a node.

Do I need to index if I only need recent data? Possibly not — direct RPC calls may be enough for live lookups. Indexing becomes necessary when you need history, aggregation, or search.

How long does indexing take? It depends on the approach. Sequential indexers process history block by block, which can take days for a large chain. Parallel engines process historical segments simultaneously.

Start indexing without running infrastructure — get an API key at thegraph.market, no personal information required.