The N+1 problem — one query for a list plus one query per item — is a general data-access anti-pattern that appears in REST, monolithic GraphQL, and federated GraphQL, not just GraphQL. In resolver-based GraphQL, the default execution model makes it easy to introduce accidentally because sibling resolvers don't coordinate fetches. In federated GraphQL, router-level batching (e.g., WunderGraph's breadth-first loading) can reduce cross-subgraph fan-out, but subgraphs can still reintroduce N+1 if their `__resolveReference` resolvers fetch one record at a time. DataLoader is the most common fix — batching `.load()` calls within a scheduling window — but joins, ORM eager loading, denormalized views, or set-based SQL queries are often better for predictable access patterns. Detection requires correlating a GraphQL operation with backend call counts via database logs, distributed traces, or APM tools, since router traces may look fine while per-entity fan-out hides inside subgraphs.
