Shopify has introduced a redesigned GraphQL execution engine, internally called GraphQL Cardinal, that replaces traditional depth-first traversal with a breadth-first execution model, reporting significant production performance improvements for large-scale query workloads. The new architecture targets inefficiencies in GraphQL execution itself rather than bottlenecks in databases or network infrastructure, an area Shopify engineers argue has remained largely underexamined in the GraphQL ecosystem.
Shopify Engineering summarized the results in a post on X, stating:
The results in production for a large GraphQL list query running breadth-first: 15x faster field-level execution, 6x less GC overhead, 4+ seconds off P50 end-to-end time.
End-to-end response time comparison of Breadth First vs Depth First traversal (Source: Shopify Blog Post)
The redesign addresses a core characteristic of conventional GraphQL execution. Most GraphQL engines traverse query trees recursively, resolving fields object-by-object in a depth-first manner. While straightforward, this approach can lead to repeated resolver invocations, fragmented memory allocation patterns, and heavy garbage collection when queries involve deeply nested, highly relational datasets such as product catalogs, variants, and inventory structures common in commerce systems.
GraphQL Cardinal changes this traversal model by executing queries level by level across collections of entities. Instead of resolving fields independently for every node in the tree, the engine batches resolver execution across groups of objects at the same depth. Shopify stated that this approach improves CPU cache locality, reduces redundant computation, and lowers per-request memory churn.
Depth-First Vs Breadth-First execution flow and field tracer (Source: Shopify Blog Post)
The redesign also changes execution orchestration internally. Instead of repeatedly invoking resolvers during recursive traversal, GraphQL Cardinal coordinates execution per query layer, enabling resolvers to process batches of entities together before moving deeper into the graph. This makes batching a native execution behavior rather than a separate optimization. The approach builds on ideas explored across the GraphQL ecosystem, including Airbnb’s batched resolvers for reducing N+1 query overhead, WunderGraph’s breadth batching experiments, and projects such as graphql-breadth-exec that explored breadth first traversal alternatives to recursive execution.
Farhan Thawar, Head of Engineering @ Shopify, described in a LinkedIn post
GraphQL Cardinal is Shopify's response to a problem hiding in plain sight: conventional GraphQL execution is algorithmically expensive at scale, and very few have questioned it.
Shopify's implementation, however, appears notable for integrating breadth-first traversal directly into production infrastructure at large scale while maintaining compatibility with existing GraphQL schemas and APIs. According to the company, the migration required coordinated changes across execution orchestration, resolver behavior, tracing infrastructure, and runtime scheduling systems.
One of the key migration challenges involved preserving existing developer-facing GraphQL semantics while changing execution behavior underneath. Existing schemas and resolvers were designed around recursive depth-first assumptions, meaning Shopify needed to adapt resolver coordination and tracing mechanisms without requiring widespread API rewrites. The company indicated that compatibility with existing GraphQL APIs was maintained throughout the rollout, allowing teams to benefit from execution improvements without changing application-level query structures.