N+1 Query Problem

Application code issues one query to fetch N parent records, then issues N individual queries to fetch each child record, executing N+1 round trips to the database instead of 1–2, multiplying database load proportionally to the result set size.

The N+1 problem is the most common ORM-induced database anti-pattern. It occurs when an application fetches a list of records and then lazily loads associations for each record in a loop. The ORM's lazy loading intercepts each association access and issues a SELECT, producing one query per parent record rather than batching the child records into a single query.

Example: a blog application renders a post list. The ORM executes SELECT * FROM posts LIMIT 100 (1 query, returns 100 rows). As each post is rendered, the template accesses post.author.name. The ORM lazily fetches each author: SELECT * FROM users WHERE id = 1, SELECT * FROM users WHERE id = 2, ... SELECT * FROM users WHERE id = 100. Total: 101 database queries for what could be 2 (posts + authors with a JOIN or IN clause).

At 100 posts per page load, the single-page request generates 101 queries. PostgreSQL executes each query in 0.5–2ms; total query time is 50–200ms, but the round-trip overhead (each query requires a network round trip, usually 1–5ms for co-located services) adds 100–500ms. At 1,000 page loads per second, the database receives 101,000 queries/second for a workload that needs only 2,000 queries/second: a 50x amplification of database QPS.

The problem scales linearly with the result set: N=1,000 (a 1,000-row export page) produces 1,001 queries. The failure often appears only in production when data volumes are larger than development environments, or when a feature is used in a context with more records than anticipated.

N+1 is not limited to ORMs: any application code pattern that queries in a loop (for item in items: db.query(SELECT ... WHERE id = item.foreign_key)) exhibits the same pattern.