What is an N+1 Query Problem?

Why the name?

The "1" is the initial query that returns a list of N rows. The "N" is the N follow-up queries — one per row — to load related data. For 50 posts loaded with their author, that's 51 total queries instead of the 2 you actually need.

The classic Laravel example

N+1 — fires 1 + 50 = 51 queries

// 1 query: SELECT * FROM posts ORDER BY ... LIMIT 50
$posts = Post::latest()->take(50)->get();

foreach ($posts as $post) {
    // 50 queries: SELECT * FROM users WHERE id = ?
    echo $post->author->name;
}

Fixed — fires 2 queries

// 2 queries: 1 for posts, 1 batched for all authors
$posts = Post::with('author')->latest()->take(50)->get();

foreach ($posts as $post) {
    echo $post->author->name; // already in memory
}

Why it matters

Every query has network and protocol overhead — typically 1-5ms on a well-tuned system. The queries themselves might be fast, but 50 round-trips stack up: a page that should run in 50ms runs in 250-500ms. Scale that to 500 items and you're in seconds territory.

N+1 is the single most common cause of slow Laravel endpoints. Finding and fixing one often cuts a page's response time by 5-10x.

How to detect N+1 in production

Model::preventLazyLoading() catches them in development. In production you need an APM that groups repeated query fingerprints per request — the signal is "the same normalized SQL fired 47 times in one request."

NightOwl gives you the data to spot it without auto-flagging: the query watcher fingerprints every statement and exposes a call_count column on the Queries page. The request detail page lists every query the request fired, so a repeated pattern is obvious at a glance — but the diagnosis is yours, not an automated threshold.