That's N+1. Here's the fix in the order that matters.

THE SHAPE OF THE PROBLEM
  query { posts(first: 50) { author { name } } }
  → 1 query for posts, then 50 for authors. 51 round trips for 50 rows.

1 — DATALOADER (does ~90% of the work)
  loaders/userLoader.js
    new DataLoader(async (ids) => {
      const rows = await db.user.findMany({ where: { id: { in: ids } } })
      const byId = new Map(rows.map(r => [r.id, r]))
      return ids.map(id => byId.get(id) ?? null)   // MUST return in input order
    })

  Two rules people get wrong:
  • Construct per request, in context — a module-level loader caches across
    users and leaks data between them.
  • The batch fn must return results positionally, same length as keys.
    Returning the raw DB rows silently mismatches when a row is missing.

  51 queries → 2.

2 — DEPTH LIMIT — stop the pathological query, don't just make it fast
  depthLimit(7) in validationRules. A client can nest
  author→posts→author→posts forever; DataLoader makes that efficient, not
  bounded.

3 — COMPLEXITY SCORING
  Cost per field, reject over budget. first: 1000 on three nested
  connections passes a depth limit and still melts the DB.

4 — CONNECTION PAGINATION on every list field
  Unbounded lists are the thing depth limits can't save you from.

IF YOU'RE FEDERATED
  Each subgraph needs its own loaders — the gateway batches entity
  resolution across subgraphs, but not within one. A @key reference
  resolver without a loader is the same N+1, one layer down.

Start with #1 and re-measure before doing the rest.