Indexing Co vs Subgraphs (The Graph)
How Indexing Co's pipeline architecture compares to The Graph's subgraph model for blockchain data indexing.
Subgraphs were a breakthrough when Ethereum was the only chain that mattered. Define a schema, write AssemblyScript mappings, deploy, and query via GraphQL. Simple. But crypto has changed: more chains, faster blocks, different VMs, and use cases far beyond powering a frontend.
Indexing Co was built for this reality. Here's how the two approaches compare.
Architecture
Subgraphs: Contract-Centric, Coupled
Subgraphs bundle indexing logic, database schema, and storage into one unit. They're contract-centric -- you define which contract events to index, write mappings in AssemblyScript, and query results through a GraphQL endpoint.
This coupling creates friction: - Change your schema? Re-index from block zero. - Need data from a new chain? Deploy a separate subgraph. - Want SQL access? Not available -- GraphQL only. - Need wallet data, block data, or cross-chain data? Out of scope.
Indexing Co: Pipeline Architecture, Decoupled
Indexing Co separates sourcing, transformation, and delivery into independent layers. Each layer can change without affecting the others.
- Source: Connect to any chain. Add new chains without rewriting transforms.
- Transform: Write TypeScript (not AssemblyScript). Change your logic without re-indexing.
- Deliver: Data goes to your PostgreSQL, BigQuery, webhook, or GraphQL endpoint. Your choice.
Feature Comparison
| Indexing Co | Subgraphs (The Graph) | |
|---|---|---|
| Language | TypeScript | AssemblyScript |
| Query interface | SQL, GraphQL, webhooks | GraphQL only |
| Data destination | Your database | Hosted GraphQL |
| Multi-chain | Single pipeline definition | Separate subgraph per chain |
| Schema changes | Hot-swap transforms | Full re-index required |
| Latency | 2.54s median | Seconds when synced, hours to days for initial sync |
| Data scope | Contracts, wallets, blocks, transactions | Contract events only |
| VM support | EVM, Solana, Cosmos, Move | EVM-focused |
| Chains | 100+ | 60+ |
| Reorg handling | Built-in confirmation depth | Varies by host |
| Backfill speed | Hours for full history | Hours to days (re-index) |
Where Subgraphs Fall Short
Performance at Scale
A synced subgraph can keep up with the chain head in seconds, but initial syncs and re-indexes take hours to days for high-volume contracts. Under load, latency degrades as indexing falls behind. Indexing Co maintains sub-3-second latency regardless of volume because sourcing and computation are separated from storage.
Multi-Chain Pain
A DeFi protocol on Ethereum, Base, Arbitrum, and Polygon needs four separate subgraphs, four databases, and four maintenance burdens. With Indexing Co, one pipeline definition covers all four chains with a unified output schema.
Schema Lock-In
Need to add a field? Track a new event? Change your data model? With subgraphs, that means re-indexing from scratch -- a process that can take days for high-volume contracts. Indexing Co lets you modify transforms and reprocess without starting over.
The AssemblyScript Tax
AssemblyScript is a subset of TypeScript that compiles to WebAssembly. It's limited, poorly documented, and has a fraction of the ecosystem. Indexing Co uses standard TypeScript with access to the full npm ecosystem.
When to Use What
Use subgraphs if you're building a simple, single-chain frontend that only needs contract event data and you're comfortable with GraphQL.
Use Indexing Co if you need multi-chain support, sub-3s latency, SQL access, custom delivery targets, non-EVM chains, or data beyond contract events.
Related Reading
Make the Switch
Migrate from subgraphs to Indexing Co pipelines. Most teams are up and running in a day.