In Laravel 13, what does Model::automaticallyEagerLoadRelationships() change about lazy loading, and when would you still write with() yourself?

## What the switch does Eloquent normally treats every model on its own: reading `$user->posts` on an unloaded relation runs a query for that one user. **Automatic eager loading** changes the unit of work from the model to the **collection it came from**: ```php use Illuminate\Database\Eloquent\Model; public function boot(): void { Model::automaticallyEagerLoadRelationships(); } ``` With the switch on, every Eloquent collection a query returns is given an autoload callback. When code reads an unloaded relation on any model in it, the callback loads that relation for every model **of the same class in the same collection** that does not have it yet, using a single where-in query, much like `$collection->loadMissing('posts')`. ## Nested access is batched too The loaded children inherit the autoloader. In the docs' own example: ```php $users = User::all(); foreach ($users as $user) { foreach ($user->posts as $post) { foreach ($post->comments as $comment) { echo $comment->content; } } } ``` Without the switch this runs one `posts` query per user and one `comments` query per post. With it, the first `$user->posts` loads posts for all users, and the first `$post->comments` loads comments for all posts reached through those users: three queries in total. To opt in for one collection instead of globally, call `withRelationshipAutoloading()` on it: `User::where('vip', true)->get()->withRelationshipAutoloading()`. A single model has the same method. ## Where it does not help The autoloader only answers one question: "this relation is unloaded, load it for my siblings". Everything else still needs an explicit decision: - **Constraints and columns.** It loads the whole relation. A filter (`with(['posts' => fn ...])`), a column list (`with('author:id,name')`) or a per-parent limit must be written by hand. - **Aggregates.** `$post->comments->count()` would autoload every comment just to count them; `withCount('comments')` or `loadCount('comments')` fetches only the number. - **Relation method calls.** `$post->comments()->latest()->first()` is an explicit query per post; the autoloader never sees it. - **One-by-one fetches.** Models retrieved in a loop with `find()` each live in their own collection of one, so there is nothing to batch across. - **Visibility.** The queries still happen inside the view, at access time. The page is faster, but a reviewer cannot read its data needs from the controller. ## What it costs - **Over-fetching.** Reading a relation on one model loads it for every model in the collection. A conditional read on the first of 500 rows still loads the relation for all 500. - **Whole rows.** The autoloader selects every column of the related table; wide tables cost memory that a column list would have saved. - **Deferred timing.** Queries run wherever the relation is first read, often in a Blade partial, so the query log no longer lines up with the controller. - **Global reach.** A static switch affects queue workers, console commands and exports too, which may prefer the old per-model behaviour or explicit loading. None of these is a reason to avoid it; they are the reasons explicit `with()` stays the default in code that is reviewed for performance. ## How it interacts with strict mode When a relation is read, Eloquent tries the autoloader **before** the lazy-loading check. If `preventLazyLoading()` is also on, relations the autoloader can serve never raise `LazyLoadingViolationException`. That makes the two switches partly exclusive in effect: strictness is a tool for finding missing eager loads, autoloading is a tool for tolerating them. Teams usually pick one stance per codebase: | Stance | Switches | Good fit | |---|---|---| | Explicit | `preventLazyLoading(! isProduction())`, `with()` everywhere | APIs and pages where query plans are reviewed | | Tolerant | `automaticallyEagerLoadRelationships()` | admin panels, internal tools, legacy views with deep loops | | Mixed | autoloading on selected collections via `withRelationshipAutoloading()` | a legacy page being migrated while the rest stays strict | ## How to answer in an interview State that the feature is opt-in and batched per collection, give the three-query nested example, and then list its limits: no constraints, no aggregates, no help for relation method calls or single fetches. The senior signal is the trade-off: it removes the most common N+1 without code changes, at the price of hiding the query plan and silencing the strict-mode alarm.