Managed Subgraphs

Keep your Subgraph indexed without running the indexing infrastructure yourself. With Managed Subgraphs, you can monitor progress, prepare a new version while the current one serves queries, and choose manual releases or follow versions published on The Graph Network.

Pair a Managed Subgraph with an Endpoint Alias to keep the same application URL across upgrades. If you only need to query an existing deployment, start with Query your first Subgraph.

Start indexing

Before you start, check that you have:

• An Owner or Developer role in the organization.
• A positive available credit balance. Support can arrange a credit exception when appropriate.
• Room in your plan's Managed Subgraph quota.
• A deployment with a valid manifest and query schema that uses one supported network across all data sources and templates.

Then add the Managed Subgraph:

1. Open Subgraphs in the platform and add a Managed Subgraph.
2. Give it a name your team will recognize. Choose its Target type: Deployment CID for a pinned version that you upgrade manually, or Graph Network Subgraph ID to follow future published versions automatically. A Graph Network Subgraph ID resolves its latest published deployment before indexing begins.
3. Enter the identifier. A Deployment CID starts with Qm and has 46 characters; a Graph Network Subgraph ID has 43 or 44 characters. The form reports an incomplete or malformed identifier before checking anything.
4. Wait for the manifest check. The form shows the deployment's network and start block. Fix any reported problem, or retry a check that could not complete from the button beside the field, then create the Managed Subgraph.
5. Optionally name an Endpoint Alias that follows this Managed Subgraph, so your application keeps one query URL across upgrades, then get its query endpoint. You can skip this step and add an Endpoint Alias later. If the Endpoint Alias can't be created, for example because the name is taken, your Managed Subgraph is still created: retry with another name or skip.

Know when your data is ready

Check indexing progress and health before relying on new data. The Managed Subgraph page leads with its status, sync lag, network, estimated hourly cost, Target type and the Deployment CIDs it serves.

• Available means the current version is healthy and serving queries close to the network head. A small lag can remain, and the page always shows how many blocks it is behind. Check that lag when your application needs the most recent block.
• Status updated tells you when the status was received, not which block has been indexed. If a measurement is unavailable or older than expected, check again before making a release decision.
• Get query endpoint connects through the Managed Subgraph's earliest created linked Endpoint Alias, which follows promotions. Without a linked Endpoint Alias, it connects to the current Deployment CID, which doesn't follow upgrades.

Once you can query the deployment, include _meta to check the block and deployment serving your response. Monitor sync health shows how to detect lag and indexing errors from your application.

Upgrade without changing your application URL

Your Current version continues serving queries while you prepare a Next version. Your Endpoint Alias moves only when you promote:

1. Choose Start upgrade from the page's actions and enter the next Deployment CID. It must use the same network.
2. Review the schema comparison. If it reports breaking changes, update and test affected clients before proceeding. You can deliberately continue with a breaking change.
3. Let the next version index, then test its query results. A compatible schema does not guarantee unchanged data or mapping behavior.
4. Choose Promote version when the next version is healthy and meets the service's indexing readiness checks. Review its indexing progress against the network head before promoting.

An Endpoint Alias with a Managed Subgraph target follows the version you promote, so your clients keep the same URL. An Endpoint Alias with a Deployment CID target stays on that CID. Existing Endpoint Aliases only follow these upgrades after you explicitly target the Managed Subgraph. See Manage Endpoint Aliases.

You can cancel an upgrade before promotion. After promotion, returning to a previous deployment requires another upgrade; it is not an instant rollback. Keep the previous CID and test your recovery plan before a production release.

Follow published upgrades automatically

Choose a Graph Network Subgraph ID at creation, or select Convert target to Graph Network Subgraph ID on an existing Managed Subgraph. Following authorizes indexing and promotion of future published versions, including breaking schema changes. Review the displayed schema comparison and prepare clients for changes published by the Subgraph owner.

You don't stage these upgrades in GraphOps:

• When the owner publishes a new version on The Graph Network, the latest version becomes Next while Current continues serving.
• Next promotes when it is healthy, attached, and ready to serve queries.
• If another release arrives first, the latest valid release replaces Next. Serving Current can therefore be older than the previous published network version.
• Missing or deprecated IDs, lookup failures, invalid releases, and network changes hold the existing versions and Endpoint Alias mappings. Check the last resolution and tracking error on the Managed Subgraph page.

To convert an existing Managed Subgraph, it must be active with no staged manual upgrade, its current CID must be in that ID's published history, and the ID must use the same blockchain network. Cancel a manual upgrade before converting. Your name, version history, and linked Endpoint Aliases stay with the resource. Paused resources keep their following choice and resume with the latest version.

To stop following, choose Convert target to Deployment CID. Converting keeps Current and retires Next, and manual upgrade controls become available again.

An Endpoint Alias with a Graph Network Subgraph ID target follows its latest validated publication independently of Managed Subgraph indexing readiness. Use a Managed Subgraph target when the Endpoint Alias should follow its serving Current version. Manage Endpoint Aliases shows when each target moves.

Plan indexing costs

Managed indexing charges depend on how long each version receives indexing service, its entity count, and its stored data. Charges can accrue during setup, syncing, and degraded operation, not only when you send queries. Use the cost estimate to plan spending; it is not a final bill.

The managed query rate applies when your organization's request resolves to its managed deployment, whether you use a Deployment CID, Endpoint Alias, or Graph Network Subgraph ID.

During upgrades, both Current and Next can accrue indexing charges. The previous version can continue accruing charges until its indexing service is removed. Your plan quota counts the Managed Subgraph once, even while two versions are active. Separate Managed Subgraphs sharing a CID each occupy a quota slot, and their attached registrations are charged separately.

If credits run out, existing indexing can continue accruing charges until the grace period ends and disconnection is confirmed. See Managed Subgraphs during a pause for stopping and recovery after adding credits.

Check your plan's capacity

Review each plan’s included features in Billing and credits. The platform shows your current organization’s capacity when you add a Managed Subgraph.

Paused Subgraphs and those being removed still count toward your quota. Capacity becomes available after removal finishes.

Stop indexing a Subgraph

Removal is irreversible and stops managed indexing. Check that your applications no longer depend on that service before proceeding.

1. Choose Convert target to Deployment CID if a following resource has Next, or cancel a staged manual upgrade.
2. Delete the Endpoint Aliases that target this Managed Subgraph, or change them to Deployment CID targets.
3. Select Delete and confirm deletion of the Managed Subgraph.
4. Check that removal finishes before reusing its quota or name.

The record remains under Archived, with its version history. Once removal finishes, you can reuse the name for a new Managed Subgraph; the archived record remains available. You can create another resource with the same CID while a peer is still active.

Next steps