What is subgraph?

A published indexing definition that says which contract events to read and how to shape them for querying, used by The Graph and compatible tooling.

It moves indexing from private infrastructure to a shared, open definition anyone can run or query, which is why many applications' data layers are subgraphs rather than in-house databases. The trade-off is dependency: a broken or unmaintained subgraph makes an interface look empty even though the underlying contracts are working. Subgraphs read events, so anything a contract does not emit cannot be indexed this way. Reindexing after a change takes time in proportion to the history being read, which is why a freshly deployed subgraph can lag the chain by hours before it is useful. See indexer.

This is invisible infrastructure that becomes visible in one situation: when a decentralized application shows you a zero balance or an empty history while your funds are demonstrably fine on chain.

How it works

A blockchain node is good at answering "what is the state of this contract right now" and bad at answering "show me every trade this address made, newest first". The second question needs an index, and building one means replaying history.

A subgraph is the recipe for that replay. It names the contracts and the starting block, lists the events to listen for, defines the shape of the resulting data, and includes the handler code that turns an event into a stored record. An indexer runs the recipe, walks the chain from the starting block forward, and serves queries against the result (source: The Graph documentation).

Three consequences follow directly from the design.

Events are the input. If a contract does not emit an event for something, no subgraph can index it, and the fix is a contract change rather than a query change.

Reindexing is proportional to history. Changing the definition means replaying from the start block, which for a busy contract with years of history takes hours or days.

Freshness is not guaranteed. An indexer lags the chain head by some amount, so an interface reading from a subgraph can be behind reality, which is exactly what a user sees as a missing transaction.

Example

Illustrative. You make a swap, the transaction confirms on chain, and the application's history page does not show it. The transaction is visible on a block explorer, so nothing is lost. What has happened is that the subgraph the interface reads has not yet processed that block. Waiting resolves it. Meanwhile a second application reading the same contracts through its own indexing shows the trade immediately, which is why two interfaces to the same protocol can disagree about your history while agreeing about your balance.

Why it matters when you buy

This is decentralized application infrastructure, so it matters after a purchase rather than during one, and mainly as an explanation for confusing interfaces. The block explorer guide covers checking what actually happened on chain, which is the authoritative answer whenever an interface disagrees with itself.

Related terms

• indexer — the party that runs the definition
• event log — the on-chain data being indexed
• dapp — what reads from a subgraph
• rpc provider — the other way applications read a chain
• archive node — what deep history requires
• smart contract — the source of the events

Questions

Why does an application show the wrong balance?

Balances usually come from the chain directly while history comes from an index, so a lagging or broken index shows stale history alongside a correct balance. A block explorer settles which is which.

Can I run a subgraph myself?

Yes. The definition is public, which is the point of the design, and anyone with a node and the indexing software can serve the same data. See node.

Does this affect buying on an exchange?

No. Centralized exchanges run their own databases and do not depend on this layer. It matters only for decentralized applications. See cex.