What is the N+1 problem in GraphQL?

The N+1 problem occurs when a GraphQL query for a list of N items triggers one query for the list plus N additional queries for related data on each item. For example, querying 20 users with their orders generates 1 query for users plus 20 individual queries for each user's orders — 21 total queries when 2 would suffice.

How does DataLoader solve GraphQL N+1 queries?

DataLoader collects all individual load requests within a single event loop tick and combines them into one batched query. Instead of 20 separate queries for each user's orders, DataLoader issues one query with all 20 user IDs using an IN clause. It also deduplicates requests for the same entity within a single request.

What are persisted queries and why use them?

Persisted queries store the full query text on the server and let clients reference queries by hash. This reduces request payload size (64-byte hash vs 2-10 KB query), eliminates parsing and validation overhead (1-5ms savings per request), and enables server-side response caching keyed by query hash plus variables.

How do you cache GraphQL responses?

Two approaches: full response caching keys the entire response by query hash and variables, which works well for persisted queries and public data. Partial result caching stores individual resolver results keyed by type and ID, providing higher cache hit rates but requiring more complex invalidation logic.

API & Backend Elena Kowalski May 20, 2026 13 min read

GraphQL Performance: Query Optimization and Caching

GraphQL solves the over-fetching and under-fetching problems of REST APIs by letting clients specify exactly the data they need. This flexibility creates performance challenges that REST APIs do not face. A single GraphQL query can trigger hundreds of resolver functions, each potentially making its own database query. Without careful design, the same GraphQL endpoint that eliminates three REST round-trips can generate fifty backend queries to produce its response.

Understanding GraphQL's performance characteristics requires thinking about resolution as a tree traversal. The server walks the query's abstract syntax tree, calling a resolver for each field. Each resolver may itself query a database, call an external service, or compute a derived value. The total response time depends on the depth and breadth of this tree, the efficiency of each resolver, and whether the server can batch and parallelize work across resolvers that access the same data source.

The N+1 Problem in GraphQL

The N+1 query problem is amplified in GraphQL because the resolver pattern naturally leads to it. Consider a query that requests a list of 20 users, each with their recent orders. The users resolver runs one database query to fetch 20 users. Then the orders resolver runs once for each user — 20 separate database queries. If each order includes product details, another 20 queries fire for products. That single client query triggered 41 database queries.

# GraphQL query that triggers N+1 without DataLoader
query {
  users(first: 20) {
    id
    name
    orders(last: 5) {    # 20 separate DB queries
      id
      total
      items {            # 20 × 5 = 100 more queries
        product {
          name
          price
        }
      }
    }
  }
}
# Without batching: 1 + 20 + 100 = 121 DB queries
# With DataLoader:  1 + 1  + 1   = 3 DB queries

DataLoader Pattern

DataLoader solves N+1 by collecting all individual load requests within a single event loop tick and combining them into a single batched query. Instead of 20 separate SELECT * FROM orders WHERE user_id = ? queries, DataLoader collects all 20 user IDs and issues one SELECT * FROM orders WHERE user_id IN (?, ?, ..., ?) query.

DataLoader also provides request-scoped caching. If two different parts of the query request the same user by ID, DataLoader returns the cached result from the first load instead of making a duplicate database query. This deduplication is especially valuable in deeply nested queries where the same entities appear through different relationship paths.

Create a new DataLoader instance per request, not per application. DataLoader's cache is request-scoped by design — sharing a DataLoader across requests would serve stale data. Initialize your DataLoaders in the GraphQL context factory that runs at the start of each request.

Query Complexity Analysis

GraphQL's flexibility allows clients to craft arbitrarily expensive queries. A malicious or poorly-written client could request deeply nested relationships that trigger millions of resolver invocations and database queries. Without safeguards, a single client query could consume all available server resources.

Static Analysis and Cost Limits

Query complexity analysis assigns a cost to each field in the schema and rejects queries that exceed a maximum cost threshold before execution begins. Simple scalar fields cost 1 point. List fields cost their estimated result size multiplied by the cost of their children. Connection fields with pagination arguments cost first (or last) multiplied by the child cost.

# Schema with complexity annotations
type Query {
  user(id: ID!): User              # cost: 1
  users(first: Int!): [User!]!     # cost: first × child_cost
}

type User {
  id: ID!                          # cost: 1
  name: String!                    # cost: 1
  orders(first: Int!): [Order!]!   # cost: first × child_cost
}

type Order {
  id: ID!                          # cost: 1
  items: [LineItem!]!              # cost: avg_items × child_cost
}

# Example query cost calculation:
# users(first: 20) { name, orders(first: 10) { items { productName } } }
# = 20 × (1 + 10 × (1 × 1)) = 20 × 11 = 220 points
# With max_complexity = 1000, this query is allowed

Depth Limiting

Depth limiting is a simpler but coarser protection that rejects queries exceeding a maximum nesting depth. A depth limit of 7 to 10 is reasonable for most schemas. Depth limiting catches runaway recursive queries but does not protect against wide queries that request many list fields at the same depth level. Use it alongside complexity analysis, not as a replacement.

Persisted Queries

Persisted queries store the full GraphQL query text on the server and allow clients to reference queries by a hash identifier. Instead of sending a potentially large query string with every request, the client sends a compact hash like sha256:abc123. The server looks up the stored query, validates it, and executes it.

Persisted queries improve performance in three ways. First, they reduce request payload size — a complex query string might be 2 to 10 KB, while its hash is 64 bytes. Second, the server can skip parsing and validation for known queries, saving 1 to 5ms per request. Third, persisted queries enable response caching because the server can associate cached responses with a specific query hash plus variables combination.

Automatic persisted queries (APQ) eliminate the manual registration step. The client sends the query hash; if the server recognizes it, it executes immediately. If not, the server requests the full query text, stores it, and executes. After the first request, all subsequent requests for the same query use the hash. This approach works well for applications with a finite set of queries that repeat frequently.

Response Caching for GraphQL

Caching GraphQL responses is harder than caching REST responses because the same endpoint serves different shapes of data. A REST endpoint like /api/users/123 always returns the same shape; a GraphQL query for user 123 could request any subset of fields, each producing a differently-shaped response. Two approaches address this challenge.

Full Response Caching

Cache the entire response keyed by the query hash, operation name, and variables. This works well for persisted queries where the query set is known and stable. A query like "get homepage data" produces the same response for all users and can be cached with a simple TTL. Personalized queries (those containing user-specific data) require per-user cache keys, which reduces cache hit rates but still eliminates redundant computation for the same user making repeated requests.

Partial Result Caching

Cache individual resolver results rather than full responses. When the user resolver loads user 123 from the database, cache that result. Any subsequent query that references user 123 — regardless of which fields it selects — benefits from the cached data. This approach provides finer-grained caching with higher hit rates but requires more complex cache invalidation because a single cached entity might contribute to thousands of different response shapes.

Strategy	Cache Key	Hit Rate	Invalidation Complexity	Best For
Full response	query_hash + variables	Medium	Low	Persisted queries, public data
Partial result	type:id + field_set	High	High	Dynamic queries, entity-heavy schemas
CDN edge	query_hash + headers	High for public	Low	Read-heavy public APIs
No cache	N/A	N/A	N/A	Real-time data, mutations

Schema Design for Performance

Pagination Design

Every list field in a GraphQL schema should be paginated. Unbounded lists are the GraphQL equivalent of SELECT * FROM orders without a LIMIT — they work with small datasets and catastrophically fail at scale. The Relay connection specification (with edges, node, and pageInfo) provides cursor-based pagination that maintains consistent performance at any depth.

Set reasonable defaults and maximums for pagination arguments. A first argument with a default of 10 and a maximum of 100 prevents clients from accidentally requesting unbounded data. Include these limits in your complexity analysis so that the cost calculation reflects the actual maximum number of results a query could return.

Avoiding Over-Resolution

Design resolvers to only execute expensive operations when the client actually requests the fields that require them. If a User type has a totalSpent field that requires aggregating all order totals, that aggregation should only run when the client includes totalSpent in the query. Check which fields the client requested (using the info resolver argument) before running expensive computations.

For fields that require joining with external services, consider making them explicit nullable fields or separate types that the client opts into. This communicates the performance cost in the schema itself: a shippingEstimate that calls an external shipping API should not be a default field on every Order — it should be a field that clients deliberately request, understanding that it adds latency.

Monitoring GraphQL Performance

Standard APM tools that track endpoint-level metrics provide insufficient visibility for GraphQL APIs because all queries hit the same endpoint. GraphQL-specific monitoring must track performance at the operation level (which named query or mutation was executed) and the field level (which resolvers are slowest).

Capture resolver-level tracing that records the execution time, parent type, and return type for each resolver invocation. Aggregate this data to identify the slowest resolvers, the most frequently called resolvers, and the resolvers with the highest error rates. The resolver that runs in 3ms is not a problem when called once, but when it is called 500 times per request due to a deeply nested list query, it contributes 1.5 seconds to the response time.

Track query complexity scores alongside response times. A sudden increase in average query complexity indicates that clients are requesting more data, which may require schema changes, DataLoader optimizations, or adjusted complexity limits. Correlate complexity scores with error rates to set your complexity threshold just above the heaviest legitimate queries while blocking expensive outliers.