For years, I treated N+1 query problems as something I had to hunt manually.
I would optimize one page, feel good about the improvement, and move on. A few weeks later, I would find another controller, another view, or another API endpoint where a relationship was being loaded inside a loop.
Fix it.
Move on.
Then find another one.
And another.
At some point, I realized I was spending more time discovering N+1 problems than actually fixing them.
The Hidden Cost of Lazy Loading
One of the reasons N+1 queries are so common is that Laravel makes relationships incredibly easy to use.
You write something like:
foreach ($users as $user) {
echo $user->posts->count();
}The code looks innocent. It works. It passes testing.
But behind the scenes, Laravel may be executing additional queries for every user in the collection.
With a few records, you probably won’t notice.
With hundreds or thousands, performance starts to degrade quickly.
The problem isn’t that lazy loading exists. In many situations, it’s convenient and perfectly valid.
The problem is that it often happens silently.
The One Line That Changed My Workflow
Then I discovered this:
Model::preventLazyLoading(! app()->isProduction());A single line that can be added inside your AppServiceProvider.
When enabled in development, Laravel will immediately notify you whenever lazy loading occurs. Depending on your configuration, it can even throw an exception.
Instead of discovering N+1 problems through profiling tools or user complaints, you discover them while writing code.
That’s a completely different workflow.
Why This Matters
What I like most about this feature is that it doesn’t try to solve the problem automatically.
Laravel isn’t guessing what relationships should be eager loaded.
It simply makes the issue visible.
And visibility is often the hardest part.
Many performance problems survive because developers don’t know they exist. The application works, the tests pass, and everything appears normal until the data grows.
By preventing lazy loading during development, Laravel turns a hidden performance issue into an obvious one.
That’s often enough.
Development vs Production
In production, most teams leave lazy loading prevention disabled or handle it differently.
Some choose to log violations instead of throwing exceptions. Others integrate monitoring tools to track occurrences.
The important part is not necessarily enforcing it in production.
The important part is catching the problem before production.
That’s where the biggest value comes from.
Small Features, Big Impact
One thing I’ve learned over the years is that some of Laravel’s most valuable features are not the flashy ones.
They’re the small features that quietly improve your development habits.
Features like route model binding, queued jobs, API resources, form requests, and lazy loading prevention don’t feel revolutionary at first. But once they become part of your workflow, it’s hard to imagine working without them.
This is one of those features for me.
What I Wish I’d Known Earlier
Looking back, I wish I had enabled preventLazyLoading() much earlier.
It wouldn’t have magically solved every performance problem. It wouldn’t have replaced profiling or careful architecture decisions.
But it would have helped me spot countless N+1 issues before they made it into production.
And sometimes that’s exactly what a good framework feature should do.
Not solve every problem for you.
Just make the important ones impossible to ignore.
Now I’m curious: What Laravel feature did you discover much later than you should have? Sometimes the best productivity improvements come from features that have been sitting in the framework for years, quietly waiting to be noticed.