The Graph: Web3 Data Infrastructure

The Graph has outgrown its old nickname

Calling The Graph the Google of blockchains was once a useful shortcut. It explained the central idea: blockchains contain public information, but applications need an index before they can retrieve that information quickly. The nickname now hides as much as it reveals. The Graph in 2026 is not a search engine, and it is no longer only a place to publish GraphQL subgraphs. It has become a broader blockchain data stack for applications, analytics systems and AI agents.

That shift is the most important update for anyone evaluating The Graph today. Subgraphs remain the best-known product, but the official documentation now places them beside Substreams, Graph Node and Firehose. The wider ecosystem also includes Amp for enterprise-oriented data work, Token API surfaces and new Model Context Protocol tools that let compatible AI clients discover schemas and query onchain data through natural language.

The practical question has therefore changed. It is no longer simply, should this project build a subgraph? The better question is, which part of The Graph stack matches the data shape, latency, control and decentralization requirements of this application?

Why blockchain data needs an indexing layer

A blockchain is optimized to validate and preserve a sequence of state changes. It is not designed like an application database with convenient tables for every product question. A wallet may need token balances and transfers. A DeFi dashboard may need swaps, liquidity positions and fee totals. A governance app may need proposals, votes and delegate histories. Extracting those views directly from raw nodes can require custom ingestion, replay logic, storage and constant maintenance.

The Graph moves much of that work into reusable data definitions and infrastructure. A developer describes relevant contracts and events, defines entities in a schema, writes mappings that transform blockchain events into those entities, and deploys the result. Indexers process the specified chain data. The application then requests the organized result through an API instead of reconstructing it from raw blocks on every page load.

This does not make the underlying data automatically correct for every use case. The output is only as complete as the manifest, schema, mappings, data sources and indexing state. If a contract address is wrong, an event is omitted or an upgrade is not handled, a beautifully structured response can still be incomplete. The Graph reduces infrastructure work; it does not remove data engineering judgment.

Subgraphs remain the accessible starting point

Subgraphs are open APIs that extract, process and expose selected blockchain data, usually through GraphQL. Subgraph Studio provides the development and publishing workflow. A team can create a project, generate a deploy key, define the subgraph, deploy a development version, inspect logs, publish it to The Graph Network and issue API keys for application queries.

For many dapps, this remains the most approachable route. GraphQL lets the client request specific fields and traverse relationships defined by the subgraph schema. Existing public subgraphs can also save significant work when a trusted deployment already covers the required protocol. The Graph says its network contains more than 15,000 published subgraphs, so discovery should come before building another index from scratch.

The tradeoff is that subgraphs impose a model. Teams need to understand smart-contract events, AssemblyScript or supported mapping patterns, entity design and GraphQL query behavior. Complex nested queries can be expensive or slow. Chain reorganizations, contract upgrades and schema migrations must be considered. A subgraph is not a generic query over every fact a blockchain has ever stored; it is a deliberately constructed view.

Substreams serves a different kind of workload

Substreams is designed for high-performance extraction and transformation of blockchain data. It processes data in parallel and can feed different sinks, making it better suited to streaming pipelines, large historical workloads and custom data products that do not fit neatly into a conventional subgraph.

This is not simply a premium version of a subgraph. The developer experience, deployment model and downstream architecture differ. A team building a familiar dapp API may prefer the schema-driven simplicity of Subgraphs. A data engineering group that needs fast parallel processing, reusable modules or delivery into its own database may find Substreams more appropriate.

Firehose and Graph Node sit closer to the infrastructure layer. Firehose provides efficient blockchain data extraction, while Graph Node is the open-source software used to index subgraphs and serve GraphQL queries. Teams that run these components themselves gain more operational control, but they also accept responsibility for nodes, storage, monitoring, upgrades and incident response. Managed access is easier; self-hosting is more controllable. Neither is universally superior.

The AI story is finally concrete

The Graph has been associated with AI infrastructure for years, sometimes too loosely. In 2026, there is a more specific reason for the label. The official AI documentation describes a Subgraph MCP server and agent skills for Subgraphs and Substreams. MCP-compatible clients can search for relevant subgraphs, inspect GraphQL schemas and execute queries against deployments. The language model is not inside The Graph. The MCP server translates tool calls into access to The Graph data, while the connected AI client interprets the user's request and returned structure.

That distinction prevents inflated claims. The Graph does not make an AI agent accurate, autonomous or financially safe. It gives an agent a standardized path to live structured onchain information. The quality of the answer still depends on the selected subgraph, its indexing status, the query, the agent's reasoning and any application-level validation.

The new interface is valuable because blockchain data has traditionally demanded specialized query knowledge. An analyst may know the question but not the exact schema. An agent can inspect that schema, generate a query and summarize results. Developers can also use agent skills for setup, debugging and testing. This lowers the interaction barrier without eliminating the need to verify source deployments and numerical outputs.

For AI products, provenance should be visible. Record the subgraph deployment ID, network, block height or timestamp, query and response used for an answer. Do not let a conversational interface turn reproducible data into an unexplained claim. If the output could trigger a trade, transfer, alert or governance action, validate it with deterministic checks and a second source where the consequences justify it.

Pricing is usage based, not a normal SaaS ladder

The old record treated The Graph as free, enterprise or custom software. That framing is misleading. Subgraph Studio users currently receive 100,000 free queries per month. Beyond that allowance, the Growth plan uses metered pricing. The official gateway documentation gives Subgraph Studio's reference rate as $2 per additional 100,000 queries. Payments can be handled by card or through a GRT billing balance on Arbitrum, and API keys can have monthly spending limits.

The query bill is only one part of production cost. Teams may still pay for development, testing, monitoring, RPC access, fallback infrastructure, data storage and engineering time. Self-hosting Graph Node or running network infrastructure replaces some managed charges with servers and operations. High-volume applications should model query patterns rather than multiply page views by a headline rate. One user action can generate several GraphQL requests, while caching and query consolidation can reduce traffic dramatically.

API key security matters even when the endpoint is public data. The key identifies usage and can generate charges. The Graph advises storing keys in environment variables or a secrets manager rather than hardcoding them into a codebase or exposing them in client-side applications. Subgraph Studio supports domain restrictions, access to selected subgraphs and spending limits. Use all three where they fit, then monitor query volume and rotate a key if it is exposed.

GRT is part of the network, not a developer prerequisite

The Graph Token, GRT, coordinates economic participation in the decentralized network. Indexers operate infrastructure and stake GRT. Delegators allocate GRT to Indexers. Curators signal which subgraphs may be valuable. Query fees and protocol rewards move through this system under rules that can change through governance and protocol upgrades.

A developer does not need to become an Indexer, Curator or Delegator just to build an application. A team can use public subgraphs, publish its own and pay for queries without turning protocol participation into an investment thesis. Keeping those decisions separate is healthy. Choosing The Graph as infrastructure should be based on data quality, reliability, cost and developer fit. Acquiring or staking GRT introduces market, smart-contract, delegation, operational, lock-up and regulatory risks that belong in a separate assessment.

Delegation is often described as a passive way to support Indexers, but it is not equivalent to a bank deposit or guaranteed yield. Rewards vary, token prices move, protocol parameters change and an Indexer's performance or fee choices affect results. Curation also exposes participants to economic outcomes based on signal and demand. Running an Indexer is an infrastructure business with technical and capital requirements, not a casual extension of deploying a subgraph.

This page therefore treats GRT as a protocol mechanism, not a price prediction. Nothing about query growth guarantees token appreciation, and nothing about token performance proves that a particular subgraph is reliable. Product evaluation and asset speculation should not be allowed to validate each other in a circle.

Where The Graph fits best

The Graph is strongest when an application repeatedly needs structured onchain data from supported networks. DeFi interfaces, wallets, NFT products, governance tools, explorers, analytics services and AI agents are natural fits. The network is especially compelling when a public subgraph already models the required protocol or when an open, reusable API is part of the product philosophy.

It is less suitable for offchain data, private enterprise records, general web search or workloads where the required chain is unsupported. Extremely latency-sensitive systems may need direct streaming, a specialized provider or a local pipeline. A team with unusual transformations and strict service guarantees may prefer Substreams, Amp, a commercial partner or self-managed infrastructure over a standard public subgraph.

The comparison set also depends on the job. Dune is primarily an analytics environment for SQL-based exploration and dashboards. Alchemy and QuickNode provide broader RPC and developer infrastructure. Goldsky, Subsquid and Envio compete around indexing and data pipelines with different deployment and performance models. A direct comparison should use the same chain, contracts, schema, historical depth, latency target and traffic profile.

The right proof of concept is small but demanding

Begin with one product question, not an architecture diagram. Identify the exact events and entities required to answer it. Search Graph Explorer for an existing deployment and inspect its schema, ownership, indexing status and recent query activity. Run representative queries at realistic depth and pagination. Confirm how upgrades and chain reorganizations are handled.

If no suitable subgraph exists, create one in Subgraph Studio. Start with the minimum contracts and entities needed for the product question. Add tests for mappings and known transactions. Compare indexed results against an independent block explorer or direct RPC reads. Deploy a development version, observe sync time and memory behavior, then publish only after the data model is stable.

Before production, protect the API key, restrict its domains and subgraphs, and set a spending limit. Add caching where freshness requirements allow it. Monitor indexing errors, lag, query latency, failure rates and monthly usage. Design the application so a temporary query failure does not silently become a false zero balance, missing position or incorrect alert.

For AI access, make the agent show its work. The system should retain the deployment, query parameters and time context behind important answers. Natural language is an interface, not an audit trail. When an agent cannot identify the relevant schema or gets an empty result, the safe response is uncertainty and investigation, not confident invention.

The WhatAI view

The Graph remains one of the most important attempts to make blockchain data reusable rather than repeatedly reconstructed by every application. Its advantage is no longer captured by one product. Subgraphs provide accessible open APIs. Substreams addresses fast programmable pipelines. Graph Node and Firehose support deeper infrastructure control. Horizon is expanding the protocol toward multiple data services. MCP servers and agent skills make those services easier for AI systems to discover and query.

That breadth is a strength, but it makes product selection more demanding. Teams should resist choosing The Graph because the protocol is well known or because GRT has a market price. Choose it when the data model, supported network, reliability profile and operating cost fit the application. Then choose the smallest part of the stack that solves the job.

For most developers, the best first step is still modest: find a relevant public subgraph, issue a protected API key and build one verified query into a prototype. The result will reveal more than a token narrative or a long feature list. If the data is trustworthy, the schema is usable and the operational limits are clear, The Graph can remove a large amount of undifferentiated infrastructure work. If those conditions are not met, its decentralized architecture does not excuse an unreliable product.

This overview is educational information, not financial, tax or investment advice. GRT participation and crypto infrastructure carry technical, market and regulatory risks. Product capabilities, pricing, supported networks and protocol parameters change, so verify current details in the official documentation before deploying software or committing funds.

WhatAI Decision Box

The Graph is a decentralized blockchain data stack for applications, analytics and AI agents. Its products include Subgraphs for open GraphQL APIs, Substreams for high-performance processing, Graph Node, Firehose and new MCP tooling for AI-assisted onchain queries.

Developers can discover an existing subgraph or define their own schema and mappings in Subgraph Studio, publish it to The Graph Network and query it through a protected API key. More demanding pipelines can use Substreams, Firehose or self-managed Graph Node infrastructure.

The Graph is most useful when a product repeatedly needs structured data from supported blockchains. Evaluate schema quality, indexing reliability, latency, query cost and operational control separately from any decision to acquire or participate with GRT.

Use Cases

Pricing varies by plan and region — see current pricing.

Plan features change — last updated: 2026-08-25.

The Graph (GRT) Community Discussions

Explore community discussions. Ask and answer questions on The Graph (GRT) to grow and learn together.

The Graph (GRT) Pros & Cons

How to Get Results with The Graph (GRT): Step-by-Step Workflow

1. Define the product question

   List the exact contracts, events, entities, networks, history depth and freshness required by one user-facing feature.

2. Search existing subgraphs

   Use Graph Explorer to inspect relevant public deployments, schemas, ownership, indexing status and recent activity before building another index.

3. Choose the data product

   Use Subgraphs for structured GraphQL APIs, Substreams for high-performance pipelines, or self-managed components when control justifies the operational burden.

4. Build and test the model

   Define data sources, schema and mappings, then test against known transactions, upgrades, reorganizations and independent chain data.

5. Deploy a development version

   Use Subgraph Studio or the relevant Substreams tooling, monitor sync progress and resolve deterministic indexing errors before publishing.

6. Protect production access

   Store API keys securely, restrict domains and subgraphs, set spending limits and separate development credentials from production.

7. Integrate and validate

   Add pagination, caching, error handling and application checks so missing or delayed data cannot silently become a false business result.

8. Monitor and evolve

   Track indexing lag, query latency, failure rate, cost and contract changes, then version the schema and mappings deliberately.

The Graph (GRT) Gotchas and Limits to Know Before You Start

• A subgraph returns the model its developer defined; omitted events or incorrect mappings can produce incomplete but plausible data.
• Complex GraphQL queries, deep pagination and high request volume can create latency or unexpected usage costs.
• API keys can generate charges even though the underlying blockchain data is public; use restrictions and spending limits.
• Contract upgrades, proxy changes, chain reorganizations and unsupported calls require explicit handling and testing.
• Managed gateways are convenient but introduce an access path that should be included in availability and decentralization assessments.
• Self-hosted Graph Node, Firehose or Substreams infrastructure requires servers, storage, monitoring, upgrades and incident response.
• MCP and natural-language access do not guarantee the correct subgraph, query, interpretation or answer.
• GRT staking, delegation and curation involve token price, protocol, counterparty, smart-contract and regulatory risk.
• The free query allowance does not include all development, RPC, caching, storage, gas or engineering costs.
• Supported networks and product coverage differ by component and can change over time.

Which The Graph (GRT) Feature Fits Your Use Case

Starter Prompts for The Graph (GRT)

What does The Graph do?

The Graph indexes and transforms blockchain data so applications, analytics products and AI agents can retrieve structured results without rebuilding a full custom indexing pipeline.

What is a subgraph?

A subgraph is a developer-defined open API that specifies which blockchain data to index, how to transform it into entities and how clients can query it through GraphQL.

How much does The Graph cost?

Subgraph Studio currently includes 100,000 free queries per month. The Growth plan uses metered pricing, with official documentation citing $2 per additional 100,000 queries. Infrastructure, gas and network-participation costs are separate.

Do developers need to own GRT?

Not necessarily. Developers can use the free allowance and card billing for gateway queries. GRT can fund query billing and is used by Indexers, Delegators and Curators, but those network roles are separate from ordinary application development.

What is the difference between Subgraphs and Substreams?

Subgraphs provide schema-driven GraphQL APIs for indexed data. Substreams is a high-performance parallel processing framework better suited to streaming pipelines, large historical workloads and custom sinks.

Can AI agents query The Graph?

Yes. The Subgraph MCP lets compatible clients search deployments, inspect schemas and run queries. Agent skills also support Subgraphs and Substreams workflows. The connected model still needs validation and does not become automatically accurate.

Is The Graph fully decentralized?

The Graph Network uses independent Indexers and protocol coordination, but many developers access it through managed gateways and Studio tools. Decentralization therefore depends on the component and access path being evaluated.

How should an API key be protected?

Keep keys in environment variables or a secrets manager, restrict authorized domains and subgraphs, set a monthly spending limit, monitor usage and regenerate exposed keys.

Related AI Crypto Infrastructure Tools

Explore the Network