Eloquent vs Query Builder vs SQL: Performance Test

One video from my 4-hour course "Eloquent: Expert Level".
Purchase full course here: bit.ly/eloquent-course

[@LoliPeeSlurper]

So Query Builder is a combination of both the advantages of Eloquent (Simplicity and Security) and Raw SQL (Performance). Thanks a lot for your video!

[@JoshuaKisb]

have you posted the results somewhere. so i can look at them

[@hiteshkhandar6087]

Sir, can you explain, wchich better for use in project for security and performance....

[@MuhammadFarhan-dy4ol]

How will it be laravel attendance Integration shift wise?

[@PSRENJITH]

No one said about stored procedure why?

[@mrkisilmike]

what about "sql no cache"?

[@partikpatel5655]

if there is one scenario in which we may have to implement Mongo DB in future instead of mysql database currently we have in our project. then, what should be the preferred way to write all queries using Eloquent or Using Query Builder. Can you please create a video with all the pros and cons of both and how we use different database when we needed by just changing database type

[@RealHomeboy]

If you want total abstraction bewteen models and persistence, use Doctrine in Laravel instead of Eloquent.

[@msdeav]

thank you...

[@AnirudhBabbar]

Hi!! Which chrome addon you are using for this video?

[@PovilasKorop]

It's not a chrome addon, it's Laravel Debugbar package

[@ujongg]

How to get the in-browser console laravel?

[@PovilasKorop]

It's Laravel Debugbar: github.com/barryvdh/laravel-debugbar

[@tejaspatel1810]

May I know which tool you are using for query log?

[@PovilasKorop]

Laravel Debugbar, if that's what you meant by "query log".

[@tejaspatel1810]

@@PovilasKorop yes. Excatly. Thanks

[@NathanBudd]

This is really interesting. What columns do you have indexes on for these queries?

[@LaravelDaily]

Don't remember now, to be honest, I don't think I added any indexes, except for the ones automatically added with foreign key columns.

[@NathanBudd]

@@LaravelDaily It would be interesting to run the same query, but with the name column indexed for Elloquent.

[@jashanpreet832]

What's difference between query builder and elequent please explain me in brief

[@PankajSingh-hz2gr]

In query builder you can fetch data from database by using DB . But if you go with eloquent model then u have to create model to fetch data

[@lloricode]

what editor are you using?

[@PovilasKorop]

PHPStorm.

[@lloricode]

thanks

[@lloricode]

yung db query builder when getting data with relationship is much better

[@kirchann]

Its more readable

[@webturtlesvlog]

I always prefer query builder, but interviewer always stick with the eloquent.

[@PankajSingh-hz2gr]

Same with me 😃

[@MargaRizaldiChannel]

Optimized eloquent will perform just slightly slower (almost unnoticeable) and a bit more "expensive" than query builder, but eloquent comes with uncompromised advantages like maintainability and scalability for future developments... That's why a company will always want eloquent as they need to see the future, not just the "current speed" which is historically proven will always be boosted by the technologies themselves (php, mysql, server, networking, etc.) over the time... So be wise developer... Cheers

[@opentech5972]

10,000 book at same time , who gonna query that btw . and you did not print result on test 2 and 3 so i think that effect results .on prccess.

[@taghwomillionaireo.5543]

haven't seen that done anywhere

[@chasadurrehman2306]

I build a web app for a client and it was a requirement to fetch all the questions ( 10K+ ) from the database (No pagination, No Ajax ... nothing) it was a requirement to get all the data at once. There can be many cases when you need to query much bigger data then you think.

[@ashishrawat5712]

@@chasadurrehman2306 but you can always use laravel chunk to get the data in chunks instead of fetching all the records

[@FaizanAnwerAli]

10000 is relatively very small number. Let's say your site grow by millions and you have a query which joins six or seven table (which usually happens) then Eloquent won't work that well because of not optimized query.

[@ShabbeyRoadMusic]

@@FaizanAnwerAli "Eloquent won't work that well" .. you think? You're right. It will suck, it will crash your app. Be a real programmer, learn SQL, use it. (not speaking directly to you because you obviously already know this, just trying to get people to realize they should not use the ORM for everything).

[@TheBlessingOfTurnip]

SPOILER Eloquent: 0.5 sec SQL Builder: 0.05 sec

[@kirchann]

Its not thuth challenge. Getting different result in each test.

[@orhanahmadov9381]

laraveldaily.com not working

[@PovilasKorop]

Thank you, fixed.

[@orhanahmadov9381]

@@PovilasKoropthanks. ))

[@PlayGameToday]

your macbook is trotlinng )))) xDDDD thats why eloquent stucks

[@stormcorexz]

that is a good one , but why all the heap about eloquent , i mean performance is every thing, can i sacrifice the performance in exchange of having flexible object in eloquent way

[@juanpadilla8760]

Performance is hardly everything. Most of the SMEs won't reach a point where the data they have becomes a bottleneck for the application. So what do you get with eloquent? Development speed. Use the right tool for the job always.

[@ShabbeyRoadMusic]

@@juanpadilla8760 Lol, "Performance is hardly everything". You go and tell that to the corporations that have hired me to come in and fix their scripts that ran for hours by converting the ORM/Eloquent/Doctrine junk to Raw SQL. After those conversions, the scripts ran in milliseconds instead of hours. Every time. Use the right tool for the job. Always. For databases of any significant size and complexity, that tool is SQL, or at least Query Builder - not these Active Record, or Entity, or Dapper ORMs.

[@juanpadilla8760]

@@ShabbeyRoadMusic I'm not sure what's your point, I agree that in the case of corporations that may not be the right tool for the job, but SMEs make up 99.8% of all the businesses in Europe... As I mentioned, more often than not the queries to run are not extremely complex and the volume of users is rather low in those cases. And with limited resources, development speed can make it or break it.

[@ShabbeyRoadMusic]

@@juanpadilla8760 Point taken, Juan. But I always think about how a database might scale up when I'm developing. If a developer has confidence a SME won't become a BBVA or a Marfeel, then it's fine to go the easy & quick route.

[@petrg.3752]

This is why Eloquent model has Eager Loading , look into it

[@MaizerGomes]

That is eager loading. What's your point?

[@sharkinc4563]

Dont fight

[@MarkoPetejan]

Well, for an actual library software, none of the examples would work. You would need complex SUID (CRUD) stored procedures (selects with input parameters) behaving like a table. You can not select directly from table(s) it is impossible to make such software like that. You can not manipulate the data outside the database except for a small resultset. By the way, book title and author are two properties out of more than a thousand and most of them are repeatable (ie multiple authors). And also "where title like %a%" is not usable, you have to search for every criteria (property) and for every word of search and for values in book and then combine results (some may have more than 100 thousand hits) with intersection.