We found 23 results for "eloquent performance".
Update May 2025: this course is outdated. The lessons of this course were updated and merged into a...
When it comes to the performance of the Laravel application, by far the no.1 problem I've seen is the database. DB Structure, Eloquent/SQL queries, and configuration - they all may cause many issues, so in this article, I've tried to compile "the ultimate guide" of what you need to know.
I recently worked with an Eloquent query with the `where status = 'new'` filter by ENUM value, which felt quite slow. I changed it to `status_id` instead. Was it faster? Let's find out together.
The performance of our applications is one of the top things we should care about. Inefficient Eloquent or DB queries are probably no.1 reason for bad performance. In this tutorial, I will show you the top 3 mistakes developers make when it comes to Eloquent performance, and how to fix them.
Our team is here to help. Ask us anything about Laravel development and we'll get back to you with personalized guidance.
A bit longer "checklist" video with my thoughts of how to evaluate the quality of DB structure in its early days.
This video is a 4-in-1 lesson from my course "Eloquent: Expert Level" about N+1 Query Problem.
If you work with a project that has multiple levels of hasMany relationships, you can use hasManyThrough instead, or one of a few packages I will show in this video.
Database DB Auditor provide leverage to audit your MySQL database standards and also provide options to add constraints in table.
Optimize Your DB Queries with AI
A real demo-project from an email I received, explaining the thought process step-by-step.
A free lesson from my course "Structuring Databases in Laravel 11".
An example of query optimization using withCount vs join, also adding cache on top.
Example from open-source project on how NOT to do things in Eloquent.
While optimizing Eloquent and DB performance in Laravel projects, it's not always about the number of queries or slowness of an individual query. There's one more important thing, let me show you, with an example.
Laravel has a mechanism to catch the lazy loading, but let me show you one caveat on how it works, and how to PROPERLY enable it.
In Laravel Eloquent, polymorphic structure is probably slower for queries. But by how much? Let's measure.
When counting the Model records grouped by their type in a relationship, it's tempting to load too many DB queries or too much data into the memory. There are a few ways to optimize it, let's take a look at an example.
Another "hidden gem" of Laravel which is surprisingly rarely used or even known, though it's mentioned in the official Eloquent documentation. Imagine that you have a record, and you need to check if that record already exists in the database - to prevent duplicate, you wouldn't save it second time. There's an elegant way to perform it in Eloquent.
To add a record to the database, you may use one of two methods. What is the difference?
Many of us are used to write conditional Eloquent queries with "if-else". What if I told you there's a (much) better way? Easily readable and more Laravel-ish.
If you have a query with the `belongsTo` relationship and want to order the records by the column from that related table, the orderBy wouldn't work.
Title of the article might sound unclear, but let's imagine you have customer list from Customer::all(), but then you need two separate lists/tables - customers from UK and from US. How to avoid two queries here? There's a filter() function.
Simple use-case: you want to filter only those categories which have at least one product. Or course, you write Category::with('products')->... but how do you filter out those empty categories? Those with no product? There's an app function for that: has().
