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:03 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 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.
| 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.
- Use Endpoint Aliases targeting Managed Subgraphs for production endpoints that should follow their upgrades.
- Include
_metain 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(opens in a new tab) when limits need to be raised.
Next steps
Last updated