A blockchain is very good at storing history and very bad at answering questions about it. Ask it for one transaction by hash and it answers instantly. Ask it for every transfer a wallet made last month, or every trade on one token pair, and a raw node has to scan enormous amounts of data to work it out. That gap, between storage and questions, is what an indexer fills. An indexer reads the chain once, organises the parts applications care about, and serves them through a fast query interface.
Think of it this way. A full node is a library that keeps every book in order of arrival. An indexer is the catalogue: it reads every book, notes the author, subject, and page references, and lets you find what you need without re-reading the shelves. Without a catalogue, every application would have to build its own, slowly, expensively, and inconsistently. With one, a wallet, an explorer, and a dashboard can all ask the same questions and get consistent answers in milliseconds.
Why raw node data is hard to query
A node exposes data through RPC calls, and those calls are designed around blocks, transactions, and logs, not around application questions. You can ask for the logs of one contract over a block range, but a range that spans months can be slow, rate-limited, or truncated, and you still have to decode the raw log topics and data into something your interface can display. A private RPC node, as covered in our private RPC guide, solves rate limits and latency, but it does not solve the shape problem. RPC gives you raw material. An indexer gives you answers.
There is also a history problem. A standard full node keeps recent state and prunes older data, which is fine for validating new blocks but useless for a question about last year. Answering historical questions needs either an archival node, which keeps everything at a much higher disk cost, as explained in our full vs archival guide, or an indexer that extracted the relevant history while it was current and stored it in queryable form. Most applications choose the indexer, because they only need a slice of history, not all of it.
How an indexer works, step by step
An indexer starts with a definition of what to watch. In The Graph, the best-known indexing protocol, this definition is called a subgraph: a manifest that names the smart contracts of interest, the events to monitor, and the mapping code that turns each event into stored entities. The indexer node scans new blocks, and when a block contains a matching event, it runs the mapping handler, which writes a clean record, for example a transfer with sender, receiver, amount, and timestamp, into its store. Applications then query that store through GraphQL, asking for exactly the fields they need, instead of scanning the chain themselves.
Three details decide whether an indexer is trustworthy. First, sync lag: how far behind the chain tip the indexed data sits. A dashboard that shows data ten minutes old during a launch is misleading, so lag must be monitored like any other service metric. Second, reorg handling: when the chain reorganises, the indexer must rewind and re-index the affected blocks, or it will serve data from a fork the network abandoned. Third, determinism: the same events must always produce the same indexed records, or two indexers will disagree and applications will show different numbers depending on which one they ask.
Self-hosted indexers vs indexing networks
You can run an indexer yourself, on your own node, for your own application. This gives you full control over what is indexed and how fresh it is, and it makes sense when your queries are specific, your chain is small, or your data must stay private. The cost is operational: you run the node, the indexer, the database, and the monitoring, and you fix all of them when they break. Our monitoring guide applies here too, with sync lag added as the headline metric.
Alternatively, you can use a decentralised indexing network. In The Graph Network, indexers are node operators who stake GRT to provide indexing and query-processing services, earning indexing rewards and query fees for doing so. The Graph's documentation sets the minimum stake for an indexer at 100,000 GRT, and describes proofs of indexing, cryptographic evidence that an indexer correctly indexed a subgraph up to a given block, as the mechanism that keeps indexers honest. Curators signal which subgraphs are worth indexing, and applications query through gateways or run their own infrastructure. The tradeoff is the usual one: less to operate yourself, more dependence on a network whose economics and upgrade path you should understand before building on it.
When do you actually need an indexer?
You need an indexer when your application asks historical or aggregated questions: a user's full transaction history, a token's holder list, a leaderboard, a chart over time. You probably do not need one when your application only needs current state: a balance, a single transaction status, a price from one call. Those are RPC questions, and a well-run private RPC endpoint answers them fast. A common launch mistake is building an indexer before the product needs one, and a common scaling mistake is skipping one after the product clearly does. Let the queries decide, and revisit the decision when the query pattern changes.
If you are choosing, start with a checklist. What exactly will you query, and how fresh must it be? Does an existing subgraph or indexer already serve it, or do you need a custom definition? What happens to your application if the indexer lags by ten blocks, and who gets paged? What does it cost to run yourself versus query a network, including the engineering time to operate it? Answer those five questions and the build-versus-use decision usually makes itself. If you want help working through it, DevOpsBy's node setup and managed operations services cover the node, RPC, and monitoring side, and a free infra audit is a good place to start.
Disclaimer: This post is educational only, not financial advice. Figures are listing or project data as of 2026-11-05 and may change - always confirm version numbers, requirements, and dates in the official docs before acting on them.