Indexing Subnet Data: SubQuery vs The Graph

introduction

CUSTOM VM DATA EXTRACTION

Why Subnet Indexing Requires a Different Approach

Standard EVM indexing breaks down when Subnets run custom VMs, forcing data teams to choose between protocol-native solutions and adapted general-purpose indexers.

Avalanche Subnets are sovereign blockchains that can run arbitrary Virtual Machines (VMs), not just the Ethereum Virtual Machine. When a Subnet uses a custom VM—such as a HyperSDK-based chain, a MoveVM derivative, or a gaming-optimized runtime—the block structure, transaction format, and state encoding diverge completely from the C-Chain's EVM standard. This means that general-purpose indexers like The Graph, which rely on EVM-specific event logs and call traces, cannot natively ingest data from these chains. Indexing teams must either build a custom extraction layer that translates the VM's native data model into a queryable format or adopt an indexing framework that is designed to be VM-agnostic from the start.

The operational impact is a fundamental shift in the indexing pipeline. With SubQuery, the indexing logic runs inside a sandboxed environment where the developer defines a custom processor that directly parses the chain's raw block data, mapping it to a GraphQL schema. This model treats the VM as a black box, making it well-suited for HyperSDK chains where the block format is a known, structured binary. In contrast, adapting The Graph for a custom VM requires building and maintaining a Firehose integration—a streaming data pipeline that extracts blocks from the node, transforms them into a protobuf-based format, and feeds them to the Subgraph indexer. This approach offers high fidelity but introduces significant infrastructure complexity and an ongoing maintenance burden as the VM's block format evolves.

For protocol architects and data teams, the choice between these patterns is not just about performance; it is a decision about long-term operational ownership. A SubQuery project is self-contained and can be run by the Subnet's own operators, aligning with the sovereign ethos of an Avalanche L1. A Firehose-backed Subgraph, while powerful, ties the indexing pipeline to a specific infrastructure provider and a complex data transformation layer that must be kept in lockstep with the VM's development. Teams evaluating these paths should assess whether their indexing needs require the composability of The Graph's hosted service and ecosystem or the self-sovereign, VM-agnostic simplicity of a dedicated indexer. Chainscore Labs can advise on indexing architecture, review the security of custom data extraction logic, and assess the operational risks of each approach for Subnet data pipelines.

SUBQUERY VS THE GRAPH FOR AVALANCHE SUBENT DATA

Indexing Architecture Comparison at a Glance

A side-by-side operational comparison for data teams choosing between SubQuery and The Graph to index custom VM data from Avalanche Subnets, focusing on integration effort, data fidelity, and performance trade-offs.

Area	SubQuery Approach	The Graph Approach	Operational Impact
Custom VM Data Source	Native HyperSDK support via a dedicated SubQuery VM processor. Direct indexing from custom blocks.	Requires a custom Firehose integration to transform Subnet VM blocks into a consumable stream.	SubQuery offers a lower integration lift for HyperSDK chains. The Graph demands custom infrastructure work for non-EVM VMs.
Indexing Performance	High-performance, deterministic indexing from a managed or self-hosted node. Optimized for Subnet block structures.	Performance is dependent on the custom Firehose implementation and the efficiency of the transformation layer.	SubQuery's native processor is likely to provide higher initial throughput. The Graph's performance is variable and must be validated per Subnet VM.
Data Fidelity	Direct 1:1 mapping of Subnet block data, ensuring full fidelity of custom transaction types and state changes.	Fidelity depends entirely on the Firehose transformation logic. Risk of data loss or misrepresentation if the mapping is imperfect.	SubQuery provides a higher guarantee of data integrity out-of-the-box. The Graph requires rigorous testing of the Firehose integration to ensure accuracy.
Setup Complexity	Project setup via CLI with a standard manifest file. Configuration is similar to a standard SubQuery project.	Requires setting up and maintaining a Firehose instance, writing a custom Rust component, and configuring a substreams module.	SubQuery's setup is a standard development task. The Graph's setup is a complex infrastructure and systems engineering task.
Sync Reliability	Reliable sync from the genesis block, managed by the SubQuery indexer service.	Reliability is tied to the operational health of the custom Firehose process and its connection to the Subnet node.	SubQuery provides a managed sync guarantee. Teams using The Graph must build and maintain their own high-availability Firehose infrastructure.
Query Flexibility	Standard GraphQL endpoint with full query capabilities over the indexed Subnet data.	Standard GraphQL endpoint, but the schema is defined by the custom substreams output, which may limit query patterns.	Both offer GraphQL, but SubQuery's schema is a direct reflection of the chain data, while The Graph's schema is an abstracted view defined by the developer.
Operational Overhead	Low. Teams can use SubQuery's managed service or self-host. The primary task is maintaining the indexing logic.	High. Teams must manage the Subnet node, the Firehose process, and the indexer node, in addition to the indexing logic.	SubQuery is the more operationally efficient choice for most teams. The Graph is suitable only for teams with strong DevOps capabilities and a need for its specific ecosystem.

technical-context

DATA PIPELINE ARCHITECTURE

Integration Surface: How Each Indexer Connects to a Subnet

The architectural integration points that SubQuery and The Graph use to extract, transform, and serve data from Avalanche Subnets, and the operational trade-offs each approach imposes on indexer operators.

SubQuery and The Graph connect to Avalanche Subnets through fundamentally different integration surfaces, each with distinct implications for data fidelity, operational overhead, and compatibility with custom Virtual Machines. SubQuery integrates directly at the node level via a native AvalancheJS-based interface, pulling raw block data from the Subnet's RPC endpoint and processing it through a sandboxed JavaScript or TypeScript mapping function. This tight coupling to the node's API means SubQuery can index any Subnet that exposes a standard AvalancheGo RPC interface, including HyperSDK-based chains, without requiring the Subnet to emit EVM-compatible logs or adhere to Ethereum JSON-RPC conventions.

The Graph's integration model for non-EVM chains relies on Firehose, a streaming data extraction layer that consumes block data from a chain-specific instrumented node. For Avalanche Subnets, this requires a custom Firehose integration that understands the Subnet's specific block format and transaction structure. While Firehose provides a high-performance, cursor-based stream that avoids polling RPC endpoints, it demands that the Subnet's data model be mapped into a Protobuf schema. This creates a dependency on Subnet developers to build and maintain the Firehose instrumentation, which can be a significant barrier for teams running custom VMs that diverge from standard EVM transaction formats. The operational consequence is that The Graph's indexing performance is superior for high-throughput Subnets once the Firehose integration is mature, but SubQuery offers a faster time-to-index for teams that need immediate data access without custom instrumentation work.

For teams evaluating indexing architecture, the choice between these integration surfaces is not purely about query language preference. It is a decision about who bears the burden of data extraction: SubQuery places it on the indexer operator, who must manage RPC connections and polling strategies, while The Graph shifts it to the protocol team, who must maintain Firehose instrumentation. Chainscore Labs can assess the operational cost and data fidelity trade-offs for Subnet teams planning their indexing strategy, including review of custom Firehose implementations and RPC-based indexing reliability under high load.

IMPACT ANALYSIS

Who Is Affected by This Decision

Data & Indexing Teams

Data engineers and analysts building Subnet data pipelines face a critical architectural choice between SubQuery's managed service model and The Graph's Firehose-based approach.

Key impacts:

SubQuery users must design projects around the native RPC-based indexing model, which offers faster setup but requires careful management of rate limits and connection stability for high-throughput Subnets.
The Graph users need to implement or source custom Firehose integrations for non-EVM VMs, adding significant engineering overhead before indexing can begin.
Teams indexing HyperSDK-based chains should evaluate SubQuery's native support against the development cost of a custom Firehose instrumented node.
Data fidelity requirements (e.g., handling chain reorganizations, finality depth) differ between the two approaches and must be validated against the specific Subnet's consensus parameters.

Chainscore can review your indexing architecture to ensure data pipeline reliability and completeness for downstream analytics and dashboards.

implementation-impact

INDEXING ARCHITECTURE DECISIONS

Implementation Impact Areas

Key operational and architectural considerations for teams choosing between SubQuery and The Graph to index custom VM data from Avalanche Subnets.

Data Fidelity and Determinism

Custom VMs, especially those built with HyperSDK, often use non-standard serialization and state models. SubQuery's native Rust-based indexing can parse this data directly, ensuring deterministic extraction. The Graph relies on a Firehose integration that must be carefully configured to translate custom block data into a deterministic Protobuf stream. A mismatch here can cause subgraph indexing failures or, worse, silently incorrect query results. Teams must validate that their chosen indexer's data extraction layer faithfully represents the VM's canonical state transitions without introducing normalization errors.

Performance and Latency Trade-offs

SubQuery's tight coupling with the AvalancheGo client and its RPC-based indexing model can offer lower latency for Subnet-specific data, as it avoids an extra transformation layer. The Graph's Firehose integration, while more scalable for high-throughput chains, introduces an additional processing step that can add latency. For applications requiring near-real-time data, such as live dashboards or liquidation bots, teams should benchmark the end-to-end latency from block finalization to query availability in both systems under the Subnet's expected load.

Integration and Maintenance Overhead

Integrating The Graph with a custom Avalanche Subnet requires deploying and maintaining a Firehose instrumentation for the specific VM. This is a non-trivial Rust development task that demands deep knowledge of both the VM's internals and the Firehose protocol. SubQuery's approach, which often involves a simpler, declarative project manifest and direct RPC connection, can significantly reduce initial integration time and ongoing maintenance burden. Teams should weigh the cost of specialized Rust development for a Firehose integration against the faster setup of a SubQuery project.

Decentralized Query Serving

The Graph's decentralized network allows indexers to compete to serve queries, creating a marketplace for data availability. SubQuery's decentralized network is a newer offering. For a Subnet project that requires censorship-resistant and highly available query endpoints as a public good, The Graph's mature decentralized network may be a critical requirement. Teams building permissioned or enterprise Subnets may find a managed SubQuery service or a self-hosted instance sufficient, prioritizing operational simplicity over a decentralized query marketplace.

Multi-Chain Indexing Strategy

An application may need to aggregate data from its own Subnet, the Avalanche C-Chain, and other EVM chains. The Graph's ecosystem has a broad, established network of indexers for major EVM chains, simplifying a unified data layer. SubQuery also supports multiple chains but may have a smaller indexer base for non-Avalanche networks. A team's decision should consider whether the indexing solution can serve as a single aggregation point for all their cross-chain data needs, reducing the complexity of managing multiple indexing backends.

Indexing Architecture Review

The choice of indexing middleware has profound implications for the security and correctness of the downstream application. An incorrect implementation can lead to a front-end displaying phantom balances, a governance module executing on invalid state, or a bridge relayer missing critical events. Chainscore Labs can provide an independent review of your indexing architecture, validating data fidelity from VM to query, assessing failure modes in your data pipeline, and ensuring your chosen solution aligns with your application's security and liveness requirements.

INDEXING TRADE-OFFS FOR SUBQUERY AND THE GRAPH ON AVALANCHE SUBNETS

Risk Matrix: Data Fidelity and Operational Risks

Evaluates data fidelity, performance, and operational risks when indexing custom VM data from Avalanche Subnets using SubQuery or The Graph. Helps data teams, protocol architects, and infrastructure operators identify failure modes and validation steps before committing to an indexing architecture.

Area	What changes	Who is affected	Action
Data Model Fidelity	Custom VM data structures (e.g., HyperSDK) may not map cleanly to GraphQL schemas. SubQuery offers direct RPC-based extraction; The Graph requires a custom Firehose integration for non-EVM chains.	Data teams, protocol architects, dApp developers	Verify that the chosen indexer can represent all critical state transitions without data loss. Prototype the schema against a synced Subnet node before full commitment.
Finality and Reorg Handling	Avalanche's probabilistic finality differs from Ethereum's. Indexers relying on block confirmations may serve stale or reorganized data if not configured for Avalanche's consensus rules.	DeFi protocols, exchanges, wallets, analytics platforms	Validate that the indexer's fork-handling logic respects Avalanche's finality. Test with a local network simulating deep reorgs to confirm data consistency.
RPC Dependency and Rate Limiting	SubQuery's direct RPC extraction creates a hard dependency on Subnet node availability and API rate limits. Node upgrades or congestion can stall indexing pipelines.	Subnet operators, infrastructure providers, data teams	Implement redundant RPC endpoints and monitor for rate-limiting events. For high-throughput Subnets, evaluate the Firehose streaming model to decouple from RPC polling.
Firehose Integration Complexity	The Graph's Firehose requires a custom instrumented node for non-EVM Subnets. This introduces a development and maintenance burden that may lag behind core protocol upgrades.	Protocol architects, Subnet core developers, infrastructure teams	Assess the long-term maintenance cost of a custom Firehose fork. Ensure the team has the capacity to rebase on upstream AvalancheGo releases to prevent indexing drift.
Indexer Centralization Risk	A Subnet with a single indexer provider or a self-hosted instance creates a central point of failure for all dependent UIs and applications.	dApp developers, wallet teams, end-users	Diversify indexing infrastructure or run a secondary, independent indexer for redundancy. Document the failover procedure for applications that consume indexed data.
Upgrade-Induced Schema Breakage	A Subnet VM upgrade can alter transaction structures or state layouts, silently breaking existing indexing schemas and causing data corruption.	Data teams, QA engineers, protocol upgrade coordinators	Include indexer schema validation in the Subnet upgrade test plan. Run a parallel indexer against a testnet upgrade before mainnet activation to detect breaking changes.
Operational Monitoring Gaps	Indexer health is often monitored separately from validator health. A stalled indexer can serve outdated data while the underlying chain operates normally.	SRE teams, infrastructure operators, application developers	Build unified dashboards that correlate indexer block height with the canonical chain tip. Alert on indexing lag exceeding application-specific staleness thresholds.

INDEXING PIPELINE READINESS

Rollout and Operations Checklist

A practical checklist for data teams preparing to index custom VM data from an Avalanche Subnet. This covers the critical path from chain specification to production monitoring, highlighting the divergent operational requirements of SubQuery and The Graph.

Before any indexing infrastructure is configured, the exact binary format of blocks, transactions, and receipts from the custom VM must be frozen and documented.

What to check: The custom VM's block structure, transaction format, and event/log schema. Confirm whether the chain uses standard Protobuf encoding or a custom binary format.
Why it matters: SubQuery requires a static chain definition file (chaintypes.ts) to decode the raw data. The Graph's Firehose integration requires a custom protobuf definition and a Firehose instrumented node. An unstable schema will break the indexing pipeline on every upgrade.
Readiness signal: A versioned, published specification for the chain's data structures that both the VM and indexing teams have agreed upon.

resource-links

OFFICIAL DOCS AND SOURCE REPOSITORIES

Canonical Resources

Use these resources to verify current indexing support, VM assumptions, data-source requirements, and operational behavior before committing to a Subnet data pipeline with SubQuery or The Graph.

Avalanche Documentation

Start with the Avalanche documentation to confirm the chain architecture, RPC surface, validator model, and VM type for the Subnet or Avalanche L1 you are indexing. Data teams should distinguish C-Chain-compatible EVM data, Subnet-EVM deployments, and custom VM chains because each exposes different transaction, event, trace, and state-query semantics. Before choosing SubQuery or The Graph, document the canonical chain ID, RPC endpoints, finality assumptions, block structure, event model, and any custom APIs exposed by the VM.

EXPLORE

AvalancheGo Source Repository

AvalancheGo is the canonical client implementation for Avalanche network behavior and many Subnet operational interfaces. Indexing teams should use the repository to verify API behavior, release notes, metrics exposure, and compatibility expectations when running archive nodes or RPC infrastructure for indexing. For production pipelines, pin the AvalancheGo version used by indexers, track breaking API changes, and test whether historical block retrieval, logs, traces, and custom VM endpoints remain stable across upgrades.

EXPLORE

HyperSDK Repository

For custom VM Subnets built with HyperSDK, the HyperSDK source and examples are essential for understanding action formats, state layout, block execution, and application-specific data structures. SubQuery mappings or The Graph Firehose/Substreams integrations need a deterministic interpretation of the VM’s transaction and state model, not just an EVM log feed. Use the repository to align indexer schemas with the VM implementation and to identify which data should be decoded from blocks, state transitions, or custom APIs.

EXPLORE

SubQuery Documentation and SDK

SubQuery documentation is the primary reference for project structure, manifest configuration, handlers, data models, indexing services, and deployment patterns. For Avalanche Subnet work, confirm whether the target chain can be indexed through an existing EVM-compatible path or whether a custom data source, processor, or RPC adapter is required. Teams should prototype schema mappings against real historical blocks, validate reindex performance, and define how SubQuery handles chain-specific finality, endpoint failover, and custom VM data fidelity.

EXPLORE

The Graph Documentation and Graph Node

The Graph documentation and Graph Node repository define the practical constraints for subgraph-based indexing, including supported data sources, deterministic mappings, GraphQL schema design, and node operations. Avalanche C-Chain or Subnet-EVM data may fit standard EVM subgraph patterns, while custom VM Subnets generally require additional ingestion work before Graph Node can consume the data. Verify the current support matrix, deployment target, and whether the project requires hosted infrastructure, decentralized network deployment, or a custom Firehose/Substreams pipeline.

EXPLORE

Firehose for Custom VM Data Extraction

Firehose is relevant when The Graph needs a high-throughput block stream for a chain that does not expose data in a standard EVM-compatible format. For custom Avalanche VMs, teams should expect to define block protobufs, extraction logic, cursor behavior, and replay guarantees before building Substreams or downstream Graph integrations. Use the Firehose repository to evaluate the engineering scope: chain integration, deterministic block decoding, historical backfill, fork handling, and operational monitoring for a production-grade custom indexing stack.

EXPLORE

Chains We Build On

Looking to build on a specific blockchain?

We build smart contracts, DeFi applications, wallets, tokenization platforms, and blockchain infrastructure across the major ecosystems teams choose today. That includes Ethereum, Arbitrum, Optimism, Polygon, Avalanche, Solana, Sui, Aptos, Hedera, Stellar, and NEAR, with support for additional EVM and non-EVM networks based on your product requirements.

Learn More

EVM ecosystems

Ethereum
Arbitrum
Optimism
Polygon
Avalanche
Cronos

Non-EVM ecosystems

Solana
Sui
Aptos
Hedera
Stellar
NEAR

Additional ecosystems

Polkadot
Cosmos
TON
Cardano
Algorand
Tempo

Also available for Base, appchains, custom EVM networks, and cross-chain product architecture.

INDEXING ARCHITECTURE FAQ

Frequently Asked Questions

Common questions from data teams evaluating SubQuery and The Graph for indexing custom VM data on Avalanche Subnets, with practical guidance on performance, data fidelity, and operational trade-offs.

Choose SubQuery when your Subnet uses a HyperSDK-based custom VM that emits data in formats not natively supported by The Graph's standard EVM or Substreams triggers. SubQuery's native HyperSDK integration provides direct access to block and transaction data without requiring a custom Firehose integration, which reduces initial development time and ongoing maintenance overhead.

Key indicators for SubQuery:

Your VM uses custom transaction types not expressible as standard EVM logs
You need to index state changes that occur outside of smart contract execution
Your team lacks the resources to build and maintain a custom Firehose instrumentation
You require sub-second finality indexing without additional transformation layers

Verification: Confirm that your Subnet's VM version is explicitly listed in SubQuery's supported HyperSDK VM matrix. Test with a minimal project that indexes block headers and validator set changes before committing to a full schema.

Trusted by Industry Leaders

Delivering blockchain solutions for 5+ years.

We have partnered with 50+ leading DeFi protocols, NFT ecosystems, and fintech innovators to build secure, scalable, and capital-efficient blockchain products.

Selected Partners & Clients

“I've been working with Chainscore Labs for last 3+ years, they've consistently delivered with strong ownership across multiple projects. The team is reliable and detail-oriented.”

Lee Erswell

CEO, Telos Foundation

how to get started

How to get started?

If you're looking for blockchain integration, ChainScore Labs has 5+ years of experience helping teams build and integrate exchanges, wallets, smart contracts, tokenization solutions, and protocol-connected products, we can help you choose the right path, integrate securely, and get to production faster. Our team consists of experienced blockchain developers and architects who can help you with your blockchain integration needs.

Exploration & Strategy

Define your product goals and choose the right blockchain architecture for your use case.

Architecture & Design

Design the smart contracts, tokenomics, and security parameters of your system.

Development & Integration

Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.

Security & Launch

Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.

Learn More

Explore More Solutions

Discover our
blockchain development services.

We build production-grade blockchain solutions for top-tier projects across DeFi and Web3.

Book a Call

DeFi Protocol Development

End-to-end development of custom DeFi protocols including core smart contracts and system architecture.

DEX & Exchange Development

Building high-performance decentralized exchanges with optimized liquidity and advanced trading logic.

Lending & Borrowing Platforms

Scalable credit markets and money protocols built for production-grade liquidity and security.

Indexing Subnet Data with SubQuery and The Graph

Why Subnet Indexing Requires a Different Approach

Indexing Architecture Comparison at a Glance

Integration Surface: How Each Indexer Connects to a Subnet

Who Is Affected by This Decision

Data & Indexing Teams