How do you fix N+1 queries and optimize Eloquent?

Question

Accepted Answer

The **N+1 query problem** — where accessing relationships in a loop triggers a separate query per record — is the most common Eloquent performance issue. **Eager loading** with `with()` is the primary fix, alongside other optimizations (selecting columns, chunking, indexing).

## The N+1 problem and its fix

```php
// ❌ N+1: 1 query for posts + 1 query PER post to load its author
$posts = Post::all();                         // 1 query
foreach ($posts as $post) {
    echo $post->author->name;                  // +1 query EACH → 100 posts = 101 queries!
}

// ✅ eager load with with() → 2 queries total (posts + all authors)
$posts = Post::with('author')->get();
foreach ($posts as $post) {
    echo $post->author->name;                  // no extra queries — authors prefetched
}
```

**`with()`** eager-loads relationships up front (one extra query per relationship instead of one per record), turning 101 queries into 2 — a dramatic improvement. This is the essential Eloquent optimization.

## Eager loading variations

```php
Post::with(['author', 'comments'])->get();        // multiple relationships
Post::with('comments.user')->get();                // nested
Post::with(['comments' => fn($q) => $q->latest()])->get();   // constrained
User::withCount('posts')->get();                   // count without loading (post_count)
```

## Catching N+1 automatically

```php
// in development, make lazy loading THROW so you catch N+1 problems early
Model::preventLazyLoading();    // in a service provider (dev)
// or use Laravel Debugbar / Telescope to see query counts per request
```

Tools like **Debugbar/Telescope** show query counts per page (spot N+1 visually), and `preventLazyLoading()` turns accidental lazy loads into errors during development.

## Other Eloquent optimizations

```php
User::select('id', 'name')->get();             // fetch only needed columns
User::chunk(1000, fn($users) => ...);           // process huge sets in batches (memory)
User::cursor();                                  // lazy iteration — constant memory
// + add database INDEXES on filtered/joined columns (the biggest DB-level win)
// + use the query builder / database aggregation instead of PHP loops over collections
```

## Why it matters

Fixing N+1 queries and optimizing Eloquent is critical performance knowledge for Laravel applications — the **N+1 query problem is the single most common and impactful performance issue** in Laravel, and understanding how to prevent it is essential.

The problem is insidious because Eloquent's convenient relationship access (`$post->author`) silently triggers a database query each time, so code that works fine with little data degrades catastrophically as data grows (100 records becoming 101 queries), often only discovered in production under load. **Eager loading with `with()`** is the essential fix — loading relationships up front in a couple of queries instead of one per record — and knowing its variations (multiple, nested, constrained eager loads, `withCount`) covers the common needs.

Equally valuable is knowing how to **catch N+1 problems** (Debugbar/Telescope to see query counts, `preventLazyLoading()` to turn accidental lazy loads into errors in development), so you find them before production.

Beyond N+1, other optimizations — selecting only needed columns, **chunking/cursors** for processing large datasets without exhausting memory, database aggregation over PHP-side collection processing, and crucially **indexing** filtered/joined columns (often the biggest database-level win) — round out the toolkit.

Understanding these — especially recognizing and fixing N+1 with eager loading — is important senior-level knowledge that distinguishes developers who write performant Laravel applications from those whose apps slow to a crawl as data grows, making it a frequently-relevant, high-value topic for building applications that scale.