# Usage and limits

Source: https://docs.graphops.xyz/subgraphs/usage-and-limits

Budget your Subgraphs spending and size your workloads to your organization's limits. Queries and Managed Subgraph
indexing have separate rates. Each query uses a query rate, and a Managed Subgraph also accrues
indexing charges while GraphOps keeps it indexed, not only when you send queries.

## Billing model

| Mode             | Billing behavior                                                                                                                     | Use it when                                                                    |
| ---------------- | ------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------ |
| Standard         | Each GraphQL request uses the standard query rate shown below.                                                                       | Your deployment is not registered as a Managed Subgraph.                       |
| Managed Subgraph | Indexing charges accrue hourly based on attached time, entity count, and storage. Queries use the Managed Subgraph rate shown below. | You want GraphOps to keep your deployment indexed and manage version upgrades. |

## Current credit rates

The rates below show the current query and indexing charges. Managed Subgraph estimates in the
platform use current indexing measurements and these rates; an estimate is not a bill.

Current rates as of Nov 14, 2026, 12:11 AM UTC.

| Usage component | Applies to | Rate |
| --- | --- | --- |
| Queries | Default | 50 credits per query |
| Queries | Billing mode: managed | 0 credits per query |
| Response bytes | Default | 1,500,000 credits per GiB |
| Response bytes | Billing mode: managed | 0 credits per GiB |
| Managed allocated time | Default | 100,000 credits per hour |
| Managed entity time | Default | 77,000 credits per 1 million entity-hours |
| Managed storage time | Default | 3,850 credits per GiB-hour |

During an upgrade, Current and Next can both accrue indexing usage while they are prepared. A
previous version may continue accruing briefly while its service is removed after promotion.

## Organization limits

These limits apply to your whole organization, not to each API key, and they do not change with
your plan size. [Contact support](/platform/support-and-status) for the values that apply to your
workload or to request an increase.

The primary operational limit is query rate. Each organization can also have up to 10 Managed
Subgraphs by default; see [Managed Subgraphs](./managed-subgraphs#check-your-organizations-limit).

| Limit                   | Applies to                                | Guidance                                                  |
| ----------------------- | ----------------------------------------- | --------------------------------------------------------- |
| Query rate              | GraphQL requests for the organization     | Bound worker concurrency and back off after `429`.        |
| Query timeout           | Long-running or expensive GraphQL queries | Reduce selection sets, filters, or page size.             |
| Response size           | Large entity pages and nested selections  | Page results and request only required fields.            |
| Query complexity        | Deeply nested or expensive queries        | Prefer multiple bounded queries over one unbounded query. |
| Introspection frequency | Schema discovery and code generation      | Run introspection in development or CI, not per request.  |

## Retry guidance

Retry transient `429`, `502`, `503`, and `504` responses with exponential backoff and jitter. For
large entity scans, persist pagination state and retry from the last completed cursor.

Do not retry a query indefinitely if it returns GraphQL validation errors. Validation errors usually
mean the query does not match the Subgraph schema.

## Production checklist

* Store API keys outside source code. See [Authentication](./authentication).
* Use Endpoint Aliases targeting Managed Subgraphs for production endpoints that should follow
their upgrades.
* Include `_meta` in health checks and important reads.
* Bound page sizes and use cursor-like pagination for long scans.
* Use the Managed Subgraph status timestamp when diagnosing unexpected usage.
* Contact [GraphOps support](https://platform.graphops.xyz/organizations/current/overview?support=open) when limits need to be raised.

## Next steps

* [Platform: Usage and limits](/platform/usage-and-limits): Track recorded consumption, billing-window timing, and your limit values.
* [Managed Subgraphs](./managed-subgraphs): Plan indexing costs across upgrades and removal.
* [Paginate results](./guides/paginate-results): Keep large scans inside rate and response-size limits.