This post is mainly intended for coders early in their careers, ✨vibe coders✨ and anyone using an ORM just because
We do not use ORMs
We have tried all kinds of ORMs and in the end they have all proven to be a hindrance. Our recommendation: Bite the bullet, learn your SQL and as a bonus, you will have a skill that lasts for life. ORMs add a layer of abstraction that will give you all kinds of nightmares
Now, I imagine, if you use ORMs regularly, your blood pressure went up a tiny bit, so I’ll add a caveat here:
If you are working on somewhat simple applications, without unusual reads and/or writes, sure!
Writing SELECT <something> FROM <someTable> for every case when you need to query/insert/delete/patch some data seems silly, we r…
This post is mainly intended for coders early in their careers, ✨vibe coders✨ and anyone using an ORM just because
We do not use ORMs
We have tried all kinds of ORMs and in the end they have all proven to be a hindrance. Our recommendation: Bite the bullet, learn your SQL and as a bonus, you will have a skill that lasts for life. ORMs add a layer of abstraction that will give you all kinds of nightmares
Now, I imagine, if you use ORMs regularly, your blood pressure went up a tiny bit, so I’ll add a caveat here:
If you are working on somewhat simple applications, without unusual reads and/or writes, sure!
Writing SELECT <something> FROM <someTable> for every case when you need to query/insert/delete/patch some data seems silly, we recognize that
That’s why in our specific case, where we do quite advanced SQL, process lots of logs and manage a diverse range of resources for our clients, we can’t afford to:
Learn the ins and outs of ORMs
Rely on the performance promised by ORMs
Trust that the ORM we choose is as safe or that it will be maintained as the underlying query language would
If you use an ORM, I would bet that there’s a chance that it is because you saw <insert tech influencer name here> using said ORM and you thought “Ah! This sponsored product will make me better!”
Was that the case? 🤨
If that was your reason to use XYZ ORM, that’s ok, I myself learned Haskell for a few hours because ThePrimeagen said it’s the future, I wasn’t aware it was a meme... so no shaming here friend, I’m just building awareness, that ORMs are not it 😊
Conclusion
Hopefully, my bias rant above doesn’t imply that “ORM bad”, because they are not, but they aren’t a “better” replacement for the native query language of your database
I’ll leave you with a few points you should ponder about if you lean towards using an ORM in your application:
Database read/write security
By having plain query language, you have no ‘magic’ behaviors, which facilitates audits and removes dependency on external libraries and tooling, which could introduce vulnerabilities through your ORM of choice
If you plan on getting your application audited or apply for security certifications, using ORMs will make the already painful process, much more painful
Debugging and scalability
Using ORMs obfuscates debugging since you rely on the ORM to interact with your database and complicates how your application scales
As queries grow in complexity, you can find yourself running operations through an ORM, which can have unexpected behaviors through the abstractions they offer, so if an exception is thrown, you will need to become familiar with the ORM’s inner workings, on top of knowing the underlying query language
In our opinion, it’s better to dedicate your effort to the native language of your database (which is already A LOT) rather than spending more time figuring out how to do the same work through the ORM abstractions
Portability
Abstracting how you query/insert your database to be able to change easily to a new database is naive at best
In reality, once your app complexity grows, your database will do too, so you can use whatever database-agnostic ORM to move your application from one database to another, but that doesn’t mean you will be able to just “switch” without doing any rewriting to your database queries
Sure, let’s say you move from psql to MariaDB, your ORM might do well enough and you might not have to do any rewriting, but, if you are moving to a different database, chances are that if you will be changing to a entirely different paradigm than you current database logic, in which case using an ORM will obscure the transition and give you more headaches when porting your current database logic
Using an ORM for ‘portability’ does not mean you are guaranteed a free lunch
Let me be clear again, it is ok to use an ORM, but in a time when ✨vibe coding✨ has (forcibly) become a thing, you should be aware of this ~20 year old discussion about ORMs and what you are risking in the pursuit of convenience
TLDR
ORM’s abstractions can wreck your life so be cautious
No ORM will beat learning about your database’s paradigm and their base query language, rather than relying on an abstraction
Have a great day ✌
References:
https://stackoverflow.com/questions/194147/are-there-good-reasons-not-to-use-an-orm
https://www.linkedin.com/pulse/end-orm-why-you-should-abandon-obsolete-approach-evangelista–kst6f/