DEV Community

Cover image for Why we don't use an ORM and why you (probably) shouldn't
Javier Hernandez for Diploi

Posted on

1 1 1 1

Why we don't use an ORM and why you (probably) shouldn't

Jump to TLDR? >


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/

https://news.ycombinator.com/item?id=4260288

Hostinger image

Get n8n VPS hosting 3x cheaper than a cloud solution

Get fast, easy, secure n8n VPS hosting from $4.99/mo at Hostinger. Automate any workflow using a pre-installed n8n application and no-code customization.

Start now

Top comments (0)

The best way to debug slow web pages cover image

The best way to debug slow web pages

Tools like Page Speed Insights and Google Lighthouse are great for providing advice for front end performance issues. But what these tools can’t do, is evaluate performance across your entire stack of distributed services and applications.

Watch video

👋 Kindness is contagious

Engage with a wealth of insights in this thoughtful article, valued within the supportive DEV Community. Coders of every background are welcome to join in and add to our collective wisdom.

A sincere "thank you" often brightens someone’s day. Share your gratitude in the comments below!

On DEV, the act of sharing knowledge eases our journey and fortifies our community ties. Found value in this? A quick thank you to the author can make a significant impact.

Okay