Gateway Indexing Approaches

A Gateway routes queries to Indexers on The Graph Network, but many Gateway Operators also run some indexing infrastructure of their own. This page covers when that is appropriate, The Graph Foundation’s general position on it, and the two most common reasons to run their own indexing alongside the network: staging environments and enterprise or SLA environments.

Gateway Operators as Centralized Indexers

The Graph Foundation’s position is that it is acceptable, but not recommended, for Gateway Operators to run centralized indexers alongside the network, specifically to provide staging environments or enterprise-grade support with an SLA that meets user demands. Running an Operator’s own indexing is a legitimate way to meet requirements the decentralized network does not yet serve directly, such as pre-production testing or a contractual latency guarantee. Keep in mind that running this centralized indexer can come at a high cost, diminishing the value of the network’s value prop offloading infrastructure costs to Indexers who specialize on that core compotency.

Becoming an Indexer on The Graph Network

Instead, The Foundation’s recommendation is that Gateway Operators are best off participating as an Indexer on The Graph Network rather than treating private indexing as a permanent substitute for it. In other words, Gateway Operators should use their own indexing to fill genuine gaps (i.e., staging or SLA-backed enterprise service), but do so as a network participant, contributing their indexing capacity back to the network where they can, rather than building a parallel, fully centralized service. This keeps the operator aligned with the decentralized network while still letting them meet demands the network alone cannot yet cover.

If a Gateway Operator is going to run indexing infrastructure anyway, the recommended path is to run it as an Indexer on The Graph Network. An Indexer stakes GRT, indexes Subgraphs, serves queries, and earns query fees and indexing rewards, and an Operator’s Gateway can route to their own Indexer the same way it routes to any other, on quality and cost.

Standing up an Indexer is its own body of work (the Indexer tech stack, allocations, cost models, and operations). This process is outlined in The Graph’s indexing documentation: Indexing Overview. Run through that to become a network Indexer rather than operating an isolated, off-network indexing service.

Staging Environments

The most common reason for an Operator to run their own indexing alongside the network is to provide a staging environment for their consumers. In the past, this role was filled by Edge & Node’s Upgrade Indexer and hosted service.

Staging environments typically provide:

• Pre-indexing of the latest versions: index a new Subgraph version ahead of time so a consumer can test it before any production traffic is moved onto it. This de-risks upgrades, because the new version is validated on real infrastructure first.
• Safe path to move traffic: once a new version is validated in staging, production traffic can be cut over deliberately rather than all at once.
• Debugging and log access: a staging environment a Gateway Operator controls gives the Operator and their consumers access to logs and diagnostics that are not available from independent network Indexers, which is invaluable when a new Subgraph version misbehaves.

The Upgrade Indexer is the network-aligned version of this idea: an Indexer designed to act as a fallback for Subgraph queries not yet served by other Indexers, so consumers can query a Subgraph even before the broader network has picked it up. It is not competitive with other Indexers; it exists to smooth the path onto the network. Offering a staging path is optional and depends on how much indexing an Operator is willing to run, but it is one of the clearest consumer-facing benefits of an Operator running some of their own indexing.

Enterprise & SLA Environments

The second common reason for a Gateway Operator to run their own indexing is to back enterprise commitments. Large customers frequently require guarantees the open network does not contractually provide: a latency ceiling, an uptime target, guaranteed capacity for specific Subgraphs, or priority support.

To meet these, a Gateway Operator can run dedicated indexing for the Subgraphs an enterprise customer depends on, so those queries have known, controllable performance rather than depending solely on independent Indexers’ availability. This is typically paired with a flat enterprise fee and a dedicated support channel (see Pricing & Payments and Customer Support).

To reiterate, The Graph Foundation’s position is that running dedicated indexing to honor an SLA is appropriate, and the preferred way to do it is as a participant on The Graph Network, contributing that indexing capacity to the network rather than walling it off. Done in this way, a Gateway Operator can meet demanding enterprise requirements while still strengthening, rather than bypassing, the decentralized network.