Blockchain indexer options: The Graph, Ponder, Envio, SQD or custom

A blockchain indexer reads raw chain data, such as events, transactions and state changes, and turns it into a database your app can query quickly. For most dApps in 2026 the right starting point is a framework: a subgraph on The Graph or Goldsky if you want hosted GraphQL with little ops work, or a TypeScript framework such as Ponder, Envio or SQD if you want your own database and faster iteration. Build a custom indexer when latency is measured in milliseconds, when the chain is unsupported, or when the indexer is part of the product itself.

Below is how we choose, after building indexers for trading products, explorers and governance tools.

Why you need an indexer at all

RPC nodes answer narrow questions well: what is this balance, what did this block contain. They answer product questions badly. "Show this user's positions across all pools, sorted by value, with 30-day history" would take thousands of RPC calls. An indexer processes the chain once, stores the result in a shape built for your queries, and keeps it current as new blocks arrive.

Almost every DeFi product needs one. A lending protocol needs positions and health factors for its liquidation bot. A DEX aggregator needs live pool state. A governance app needs proposals, votes and delegations. If you are planning a full stack, our guide on how to build a dApp shows where the indexer fits.

The options at a glance

The Graph

Subgraphs are still the most widely known approach. You define a GraphQL schema, map events to entities in handlers, and deploy. The handlers are written in AssemblyScript, a subset of TypeScript compiled to WASM. That is the part developers complain about most: it looks like TypeScript, but you cannot use most npm libraries, and debugging is slower than in normal Node code.

Pricing is cheap at small scale. The Graph's pricing page lists a free tier of 100,000 queries per month, then $2 per 100,000 queries, and notes that dedicated indexing requires curation with GRT.

Pick The Graph when:

• You want a public GraphQL API that other teams can query too.
• Your data model fits events-to-entities mapping without heavy external calls.
• You prefer paying per query to running servers.

Skip it when your backend needs joins against off-chain data, when you need SQL, or when you want to write handlers in ordinary TypeScript.

Goldsky

Goldsky hosts subgraphs and also runs data pipelines that stream chain data into infrastructure you control. Its own docs recommend subgraphs when you're building a dApp frontend that queries structured onchain data through an API, and they are open about the limit: subgraph latency grows as event frequency climbs. The same page says Mirror, its original pipeline product, is now legacy and superseded by Turbo, which it describes as reorg-aware.

Goldsky makes sense if you already have subgraphs and want them hosted with less hassle, or if your analytics team wants chain data in their own database rather than behind an API.

Ponder

Ponder is an open-source TypeScript framework for EVM indexing that writes results to Postgres, and you query them through GraphQL, SQL over HTTP, or directly in Postgres. The dev server hot reloads when you edit handlers, which makes iteration feel like normal backend work.

A few details from its config reference that matter in production:

• Without a DATABASE_URL it falls back to PGlite, an embedded database. Fine locally, but use real Postgres in production.
• It keeps data for reorg recovery within a reorgWindow that defaults to 180 seconds.
• The docs warn that most Ponder apps need a paid RPC plan to avoid rate limits.

Our take: Ponder is our default for EVM app backends where we own the API. Handlers in plain TypeScript and data in Postgres remove most of the friction that subgraphs add.

Envio

Envio's HyperIndex framework sits on HyperSync, its own data layer that serves chain data faster than standard RPC. Treat Envio's speed figures as vendor claims: its docs say HyperSync is up to 2000x faster than traditional RPC endpoints, and its comparison post cites a Sentio benchmark where HyperIndex finished in 8 seconds against 19 minutes for The Graph. In our experience the speed difference shows up mainly in historical backfills, which matters a lot when you change a schema and have to re-index from genesis.

Reorg handling is on by default. HyperIndex tracks per-entity state for unfinalized blocks, rolls back on reorg and reprocesses without custom handler code, and confirmation depth is configurable per chain.

SQD

SQD, formerly Subsquid, offers the Squid SDK, a set of open-source TypeScript libraries that fetch, decode, transform and persist chain data. It has processors for EVM and Substrate chains and can write to PostgreSQL, files or BigQuery. Its Portal separates finalized and recent data: one stream stays near the chain head and requires the client to handle reorgs, another only serves finalized blocks.

SQD is worth a look if you index Substrate-based chains or need to land data in files or a warehouse rather than an API.

Reorgs: the part that bites later

A reorg happens when the chain replaces recent blocks with a different version. Events your indexer already processed disappear, and different ones may take their place. If your indexer does not roll back, your database shows trades, deposits or votes that never happened.

How deep reorgs go depends on the chain. On Ethereum, a block at or below the finalized checkpoint, about two epochs or roughly 12.8 minutes back, will not reorg. Rollups and other L1s have their own rules; Arbitrum, for example, documents its own finality and reorg behavior.

Rules we follow:

• Store the block hash with every row derived from a block, so you can detect and roll back.
• Separate "pending" from "final" in the product. Show a deposit as soon as it appears, but do not credit points or trigger off-chain payouts until it is final.
• Configure reorg depth per chain. One setting copied across all chains will be wrong for some of them.
• Test it. Fork a chain locally, produce a reorg, check the database afterward.

Cost and latency

Cost has three parts: data access (RPC or a data layer), compute and storage, and engineering time. For a typical dApp the first two are small, and engineering time dominates. A subgraph can be cheaper to run and more expensive to change.

Latency also has parts: how fast blocks reach the indexer, how long handlers take, and how quickly the API serves results. Hosted subgraphs are fine for dashboards and portfolio pages. A trading UI or liquidation bot usually wants data within one block, and then the indexer belongs close to a dedicated node, with hot state in memory.

When to build your own

We build custom indexers in four situations:

1. The latency target is one block or less. The pool tracker inside a DEX aggregator is the clearest example: route search reads from memory, not from a database behind an API.
2. The chain or VM is not supported. Frameworks cover EVM chains well. Newer L1s and non-EVM runtimes often have nothing usable.
3. The indexer is the product. Explorers, analytics APIs and data businesses need full control over schema, storage and performance.
4. You need state reads, not only events. If your logic depends on contract storage at every block, event-driven frameworks get awkward and slow.

An example from our own work: aScan, a token explorer for the Aleph Zero ecosystem, runs on a Rust indexer we built for real-time processing of PSP22 token data, with a Next.js frontend and an open API. An explorer is case 3, so a framework would have been a constraint rather than a shortcut.

Custom costs more. You own reorg handling, backfills, schema migrations, monitoring and on-call. By our planning estimates, a production custom indexer for one chain and a handful of contracts takes 4 to 8 weeks to build, compared with days to two weeks for a framework-based one, and it needs ongoing maintenance after that.

A short decision path

• Public GraphQL API, low ops, EVM: The Graph or Goldsky subgraphs.
• Your own backend on EVM, SQL access, plain TypeScript: Ponder.
• Heavy backfills, many EVM chains: Envio.
• Substrate chains or warehouse destinations: SQD.
• Sub-block latency, unsupported chain, or indexer as product: custom.

If you are still choosing a chain, check indexer support before you commit. It is one of the practical factors in our guide on which blockchain to build on.

FAQ

What is a blockchain indexer?

A blockchain indexer is a service that reads blocks, transactions and events from a chain, transforms them into structured records, and stores them in a database so apps can run fast queries that raw RPC calls cannot answer efficiently.

Is The Graph still worth using in 2026?

Yes, for public GraphQL APIs and teams that do not want to run servers. Its free tier covers 100,000 queries a month. For app backends that need SQL or ordinary TypeScript handlers, Ponder, Envio or SQD are usually easier to work with.

What is the best alternative to The Graph?

It depends on the need. Ponder suits self-hosted EVM backends, Envio is built for fast backfills across many EVM chains, SQD covers Substrate chains and warehouse outputs, and Goldsky hosts subgraphs and pipelines for you.

How do indexers handle chain reorgs?

Good indexers store the block hash with derived data, detect when a block is replaced, roll back affected records and reprocess the new canonical blocks. Envio and Ponder do this by default within a configurable window.

Should I build my own blockchain indexer?

Build your own when you need sub-block latency, when your chain is not supported by frameworks, or when the indexer is the product. Otherwise a framework gets you to production faster and with less maintenance.

Talk to us

If you are deciding how to index your protocol's data, or your current subgraph has become a bottleneck, we can review your queries and latency needs and recommend a setup. Read about our indexer development work or contact 23studio.