Subgraph Migration: Moving Off The Graph's Hosted Service

The Graph's Hosted Service shut down on June 12, 2024. A practical guide to migrating subgraphs to Indexing Co pipelines without re-indexing, with TypeScript transforms and delivery to your own database.

The Graph's Hosted Service was fully sunset on June 12, 2024. Every hosted subgraph endpoint stopped serving on that date. Queries now run on The Graph's decentralized network, which prices queries in GRT tokens and asks teams to buy, stake, and manage an on-chain balance.

If you moved to the decentralized network and the token mechanics or query costs are not working for you, there is another path. You can map the same event sources into an Indexing Co pipeline, keep your logic in TypeScript, and deliver the output straight into your own database.

This guide covers what changed, where subgraphs hit limits in production, and how to move a subgraph to a pipeline step by step.

What the Hosted Service shutdown changed

Before June 12, 2024, the Hosted Service ran your subgraph for free on The Graph's infrastructure. After that date, three things changed for hosted users:

Billing moved to GRT. The decentralized network prices queries in GRT. You buy and stake tokens and manage that balance over time. Subgraph Studio includes 100,000 free queries per month, then it is paid.
You depend on third-party indexers. Query latency and uptime now depend on the indexers serving your subgraph on the network, not a single hosted backend you control.
The architecture did not change. You still write AssemblyScript, still get GraphQL only, and still re-index from block zero when your schema changes. The shutdown moved the bill and the operator. It left the limits that made subgraphs hard at scale.

That last point is why many teams used the forced migration as a moment to reconsider the model.

Where subgraphs hit limits

Schema Changes Mean a Full Re-Index Add a field or track a new event and the subgraph re-indexes from block zero. For a high-volume contract that runs hours to days, and your data is stale until it finishes.

One Subgraph Per Chain A protocol on Ethereum, Base, Arbitrum, and Polygon needs four subgraphs, four deployments, and four maintenance burdens, then you stitch the data together yourself.

GraphQL Only, Events Only No SQL, no direct database delivery, and no clean path to wallet, block, or transaction-level data. The query layer is fixed and the scope stops at contract events.

The AssemblyScript Tax Mappings run in AssemblyScript, a smaller language that compiles to WebAssembly, with a fraction of the tooling and library support of standard TypeScript.

How a subgraph maps to a pipeline

The move is direct. A subgraph couples sourcing, logic, and storage into one unit. A pipeline keeps them separate, so each layer can change without touching the others.

Subgraph: One Coupled Unit

A subgraph bundles the manifest, AssemblyScript mappings, and GraphQL schema together. Change one part and you often rebuild the whole thing from block zero.

Manifest: the contracts and events to index.
Mappings: AssemblyScript that shapes the data.
Schema: a hosted GraphQL endpoint, GraphQL only.

Pipeline: Three Decoupled Layers

A pipeline splits the same work into independent layers. Change a transform without re-indexing, add a chain without rewriting logic.

Source: chains, contracts, and events to listen to.
Transform: TypeScript, with the full npm ecosystem.
Deliver: your PostgreSQL, BigQuery, warehouse, or webhook.

Each subgraph part has a direct pipeline equivalent:

Subgraph part	Pipeline equivalent
Manifest (data sources, events)	Source config: chains, contracts, and events to listen to
AssemblyScript mappings	TypeScript transforms
GraphQL schema + hosted endpoint	Your destination: PostgreSQL, BigQuery, webhook, or GraphQL

Two differences carry most of the value. You write TypeScript instead of AssemblyScript, which usually means less code and access to normal libraries. And the data lands in your own store, so you own the schema and the storage instead of querying a hosted endpoint.

Migration steps

List your data sources. Pull the chains, contracts, and events from your subgraph manifest. That becomes the source config for the pipeline.
Port your mappings to TypeScript. Rewrite the handlers that turn raw events into your output shape. Most mapping code gets shorter.
Point at your destination. Choose where the data lands: your PostgreSQL, BigQuery, a warehouse, or a webhook. Define the output schema.
Backfill history. Run the pipeline from your start block. A full historical backfill takes hours, not the days a large subgraph re-index can take.
Cut over. Once the backfill reaches the chain head, point your application at the new store and retire the subgraph.

After cutover, changing a transform or output schema reprocesses without starting from block zero. There is no re-index every time your data model moves.

Indexing Co vs The Graph

	Indexing Co	The Graph
Architecture	Custom pipelines	Subgraphs (decentralized protocol)
Transform language	TypeScript	AssemblyScript
Query interface	SQL, GraphQL, webhooks	GraphQL only
Data destination	Your PostgreSQL, BigQuery, webhooks	Hosted GraphQL endpoint
Multi-chain	Single pipeline definition	Separate subgraph per chain
Schema changes	Hot-swap transforms, no re-index	Full re-index from block zero
Block-to-database delivery	sub-500ms (dedicated infra)	Seconds when synced, hours to days for initial sync
Data scope	Contracts, wallets, blocks, transactions	Contract events only
Chains	100+	60+
VM support	EVM, Solana, Cosmos, Move	EVM-focused
Pricing	Fixed pipeline subscription	GRT token fees (variable)
Reorg handling	Built-in confirmation depth	Varies by indexer

When to use what

Stay on The Graph if

Decentralization is a hard requirement, or you run a single-chain dApp that only needs contract event data over GraphQL and you want to build on the open subgraph ecosystem.

Migrate to Indexing Co if

You need direct database delivery, multi-chain pipelines, non-EVM support, SQL access, or lower-latency data in production without re-indexing on every change.

FAQ

When did The Graph's Hosted Service shut down?

The Hosted Service was fully sunset on June 12, 2024. Hosted endpoints stopped serving on that date, and queries moved to The Graph's decentralized network.

Do I have to re-index when I migrate a subgraph?

You run one historical backfill when you set up the pipeline. After that, changing your transform or output schema reprocesses without re-indexing from block zero, which is the opposite of the subgraph model.

Can I keep my subgraph's logic?

Yes. The event sources and mapping logic carry over. You rewrite AssemblyScript mappings as TypeScript transforms, which usually means less code and access to the npm ecosystem.

Where does the data go after migration?

Into your own destination: PostgreSQL, BigQuery, a warehouse, or a webhook. You define the output schema and own the storage, instead of querying a hosted GraphQL endpoint.

How long does a migration take?

Most teams map their sources and transforms in a day. A full historical backfill runs in hours for typical contracts.

Get Started

Move a subgraph to a pipeline. Set up your first one in under 10 minutes.

Get a Demo | Open the Console