Cosmo Performance

GraphQL performance, from first request to peak load

Query plan warming, operation hashing, cache header management, and per-phase traces. Five capabilities, built into the Cosmo Router.

Start Free Read the Docs

No third-party performance layers required.

Overview

Performance tools, built into Cosmo

The Cosmo Router ships with five performance capabilities. Each addresses a distinct bottleneck in federated GraphQL: query plan cold starts, redundant payload bytes, cache header coordination across subgraphs, and slow-phase visibility.

Persisted Operations and APQ reduce the data on the wire. Cache Control and Cache Warmer handle what gets cached and when. Performance Debugging tells you exactly which phase is slow. All five work together and require no external performance layer.

Why federation-native performance tools matter

Four problems generic tools cannot solve

Federated GraphQL has performance characteristics that HTTP proxies, generic CDNs, and APM tools were not designed to address. These problems surface at scale and require graph-aware tooling.

Query planning adds latency on every cold start.

When a router starts or restarts, the query plan cache is empty. The first execution of each operation pays the full planning cost before responding to users.

Full operation bodies repeat on every request.

GraphQL clients send the complete query text with each request. For complex operations, this adds kilobytes of redundant payload on every call.

Cache headers are hard to coordinate across subgraphs.

In a federated graph, responses aggregate data with different caching requirements. Misconfiguration risks caching sensitive data or missing caching opportunities for static content.

Slow requests have no per-phase breakdown.

Generic APM tools see HTTP latency. They cannot tell you whether delay comes from query planning, a specific subgraph fetch, or authentication. Diagnosing the root cause takes guesswork.

Cosmo Performance handles all four. No additional infrastructure, no custom wiring.

Cosmo Performance capabilities

Persisted Operations

Pre-register operations in CI/CD. Clients send a SHA-256 hash instead of the full operation body. Routers fetch registered operations from the CDN and reject anything not on the list. Three enforcement modes: log-only, safelist, or full blocking.

Free / Pro / Enterprise

Automatic Persisted Queries (APQ)

Zero-registration query caching. The first request sends the full query body alongside its hash; the router stores the mapping. Every subsequent request sends only the hash, enabling GET-based CDN caching. In-memory or Redis-backed storage.

Free / Pro / Enterprise

Use cases

Performance use cases

Real patterns where Cosmo Performance capabilities deliver measurable improvement.

Peak traffic preparation

Pre-warm query plans before a flash sale starts

Scenario

An e-commerce platform expects 10x normal traffic for a limited-time sale. Router restarts during the preceding deployment clear the query plan cache.

How Cosmo handles it

Enable the Cache Warmer at the namespace level. At router startup, it fetches a manifest of slow operations from the CDN—identified by P90 latency—and precomputes their plans. Add critical queries manually with wgc router cache push.

Outcome

Every query executes at cached speed from the first request. Cold-start latency does not appear during the sale.

Mobile bandwidth

Cut GraphQL payload size on cellular networks

Scenario

A mobile application sends complex queries that consume significant bandwidth, especially on slow connections.

How Cosmo handles it

Enable Persisted Operations or APQ. After the first execution, clients send only a short hash instead of the full query body. APQ requires no changes to CI/CD; operations are registered on first use.

Outcome

After initial registration, each request carries only a short hash instead of the full query body, cutting payload size from kilobytes to a fraction of that.

Bottleneck investigation

Identify which subgraph is adding latency

Scenario

A query spanning several subgraphs has inconsistent response times. The team needs to know whether the delay is in planning or in a specific subgraph fetch.

How Cosmo handles it

Open Cosmo Studio trace view and filter for slow operations. Compare the Operation - Planning span against the Operation - Execution span. Check the enginePlanCacheHit attribute to rule out cache misses as the cause.

Outcome

The slow subgraph is identified from the trace. The team fixes the resolver rather than guessing.

Which performance capability do you need?

If you are…	Start here
Eliminating cold-start latency after router restarts	Cache Warmer
Reducing request payload size for mobile or high-traffic clients	Persisted Operations
Reducing payload size without changing your CI/CD pipeline	Automatic Persisted Queries
Coordinating Cache-Control headers across subgraphs	Cache Control
Blocking unauthorized or expensive operations in production	Persisted Operations
Finding which phase of a request is slow	Performance Debugging
Enabling CDN edge caching for GraphQL queries	Automatic Persisted Queries

How Cosmo Performance compares

	Cosmo Performance	Custom middleware	Generic APM / CDN
Query plan pre-warming	Built-in (Enterprise)	Custom required	Not supported
Operation hash support	Built-in	Client library + server logic	Not GraphQL-aware
Cache header coordination	Automatic	Manual per-subgraph config	No federation awareness
Per-phase GraphQL spans	Built-in	Custom instrumentation	HTTP-level only
Setup time	Minutes	Days/weeks	Ongoing maintenance

Why teams use Cosmo Performance

No cold-start latency. The Cache Warmer precomputes query plans from telemetry-identified slow operations before traffic arrives. Router restarts do not expose users to planning overhead.
Less data on the wire. Persisted Operations and APQ send a short hash instead of the full query body on every request. CDN edge caching becomes possible via standard GET requests.
Cache headers correct by default. Cache Control evaluates every subgraph response and applies the strictest policy. Mutations get no-cache automatically. Error responses get no-store, no-cache, must-revalidate.
Bottlenecks visible in minutes. OpenTelemetry spans for authentication, parsing, planning, and execution are generated automatically. The enginePlanCacheHit attribute shows whether a plan came from cache.

Get started

Fast GraphQL from day one

Start Free Read the Docs