N+1 query problem is a database performance issue that occurs when software fetches a list of records with one query, then runs an additional query for related data on each record. It creates unnecessary database round trips, making pages and API responses slower as the list grows. It commonly appears in ORM-driven applications, GraphQL resolvers, and code that loads related data inside loops.
N+1 Query Problem
What Is the N+1 Query Problem?
The N+1 query problem is a database performance issue where an application loads a list of records, then runs an additional query for related data on each record. A page that loads 20 orders and separately fetches each customer may send 21 database queries. Unlike one slow database query, this repeated-query pattern becomes more costly as results grow.
How an N+1 Query Happens
In N+1, N is the number of records returned by the first query.
- An API requests the latest 20 orders.
- The application retrieves those orders in one query.
- Code loops through the orders to show each customer name.
- A lazy-loaded relationship triggers a customer query for each order.
- The request uses 1 order query plus 20 customer queries.
Why N+1 Queries Make Applications Slow
Extra queries add database work, connection use, and network round trips.
- Fewer queries keep response times more predictable as lists grow.
- Lower connection pressure leaves capacity for other requests.
- Batching can improve pages, dashboards, and API endpoints.
- Query counts are easier to test and monitor before slowdowns affect users.
N+1 Query Fixes Compared
The best fix depends on the relationship, response shape, and page size.
| Approach | Best use case | Strength | Trade-off |
|---|---|---|---|
| Eager loading | Known relationships | Preloads data with the main result | Can load unused data |
| SQL join | Small, flat responses | Often uses one query | Repeats parent rows for child records |
| IN-query batching | Lists of related records | Loads related rows in a second planned query | Requires mapping results in application code |
| DataLoader-style batching | GraphQL resolvers | Combines requests made in one execution cycle | Needs careful request-level caching |
| Selective caching | Stable, frequently read data | Avoids repeated database reads | Can return stale values |
Limits and Trade-Offs of Common Fixes
A lower query count is useful, but it is not the only performance goal.
- Joins can create duplicate rows when a parent has many children.
- Preloading every relationship can use excess memory and transfer unnecessary columns.
- Pagination can be harder when joins expand parent records.
- Caches need expiration and invalidation rules to avoid stale data.
- One oversized query can be as harmful as many small ones. Fetch only needed fields and relationships.
How to Find and Prevent N+1 Queries
Measure behavior with realistic data rather than guessing from a small test dataset.
- Inspect query logs or performance traces for repeated query shapes.
- Test list pages with realistic page sizes and relationship counts.
- Check whether repeated lookups differ only by a value passed through query parameters.
- Preload, join, or batch required related records.
- Verify query count, memory use, and response time afterward.
N+1 Queries in Applications Built With Emergent
Review database-backed pages, dashboards, and APIs built with Emergent for relationship-loading patterns during testing. When using an AI web app builder to create a full-stack product, ask for list views and API endpoints to batch related data, then validate the application with realistic records before launch.
Start Building
on Emergent today
on Emergent today
Start Building
