On this page
The core idea
The N+1 pattern appears when related data is loaded separately inside a loop. The page may look fast with a few records and become slow as the list grows. Fixing it usually means fetching related data deliberately through a join, batch query or suitable data-loading strategy, while preserving access boundaries and limiting the result size.
A practical approach
Step 1
Count database calls for one page request. Compare the count when the visible list grows from a few items to many.
Step 2
Identify the repeated relationship lookup and fetch the required related records in a bounded batch.
Step 3
Measure the resulting query size and memory use. Avoid replacing many small queries with an unbounded query that returns far more data than the page needs.
Worked example
A course catalog loads twelve courses and then queries the instructor for each card. If several courses share an instructor, much of the work is repeated. Fetching the relevant instructors together and mapping by ID can reduce repeated round trips.
A mistake to avoid
A broad join can duplicate parent rows when several child relationships are combined. Inspect result cardinality and pagination behaviour rather than judging the fix only by query count.
Try it yourself
Instrument a list endpoint and record its database call count at three page sizes. Refactor the repeated lookup and verify that the count no longer grows linearly with visible items.
Your implementation checklist
- Query count is measured per request.
- Related data is fetched deliberately.
- Batch size remains bounded.
- Pagination and duplicate rows are checked.
Share or cite this guide
Innovate with Ajay Editorial (2026-10-04). Spot N+1 Queries before a List Page Slows Down. https://innovatewithajay.com/blogs/prevent-n-plus-one-query-patterns