N+1 query
One query for the list, then one more per item. 50 rows on screen, 51 trips to the database, and a page that crawls.
See it
What it is
One query fetches the list of 50 posts. Then your code loops over them and asks for each post's author, one query at a time. That is 51 round trips where 2 would do, and every one pays full network latency. The name is literal: N queries plus the 1 that started it.
It almost always comes from lazy loading. An ORM makes 'post.author.name' look like a property access when it is really a hidden SELECT, and GraphQL resolvers do the same thing one field at a time. The fixes: eager load the relation up front (include, with, preload, joinedload), batch by id with a single WHERE id IN (...) and stitch in memory, or use a DataLoader to collect ids per tick and issue one query. A join works too, but batching avoids fan-out on one-to-many relations.
Gotcha: it is invisible in development. With 5 seed rows the extra 5 queries cost nothing; with 5,000 rows and 2ms of network latency each the endpoint takes 10 seconds. Catch it by counting queries per request in your logs, or turn on a strict mode that throws when a relation loads lazily (Rails strict_loading, Sequelize and Prisma query logging, an APM waterfall full of identical spans).
Ask AI for it
Find and fix the N+1 queries in this code. Show me which loop or resolver fires a query per row, then rewrite it to fetch related data in one pass: eager-load the relation up front, or collect the ids and issue a single WHERE id IN (...) query and map results back in memory. Do not introduce a join that fans out rows on one-to-many relations. Add a test or log assertion that the endpoint issues a constant number of queries regardless of result count.