Thomas Hunter II
Oct 5, 2022 ⋅ 16 min read

Node.js ORMs: Why you shouldn’t use them

Thomas Hunter II Thomas has contributed to dozens of enterprise Node.js services and has worked for a company dedicated to securing Node.js. He has spoken at several conferences on Node.js and JavaScript, is the author of Distributed Systems with Node.js, and is an organizer of NodeSchool SF.

Recent posts:

7 TUI Libraries For Creating Interactive Terminal Apps

7 TUI libraries for creating interactive terminal apps

When writing applications, a good user interface is just as important as the actual app’s functionality. A good user interface […]

Yashodhan Joshi
Jun 14, 2024 ⋅ 18 min read
Expo Router Adoption Guide Overview Examples And Alternatives

Expo Router adoption guide: Overview, examples, and alternatives

Expo Router provides an excellent file-based routing solution with crucial features such as deep linking and native support.

Marie Starck
Jun 13, 2024 ⋅ 8 min read
Superglue Vs. Hotwire For Modern Frontend Development

Superglue vs. Hotwire for modern frontend development

Explore how Superglue and Hotwire revolutionize frontend development with HTML over the wire, enhancing performance, flexibility, and ease of use.

Frank Joseph
Jun 12, 2024 ⋅ 7 min read
Using Pocketbase To Build A Full Stack Application

Using PocketBase to build a full-stack application

PocketBase is a performant Go-based tool that comes with essential features like user auth, file uploads, access control rules, and more.

Rahul Padalkar
Jun 11, 2024 ⋅ 18 min read
View all posts

82 Replies to "Node.js ORMs: Why you shouldn’t use them"

  1. It’s true! ORM (object-relational mapping) doesn’t fit to the current needs of coding. And when it comes to Node.js ORMs, things get complicated and needs simplified solution. Therefore, i find this article good in this case.

  2. Reason one is that ORMs are some sort of super complex thing to learn, when in reality the entire reason we use them is because they’re much more developer friendly than interacting with the database directly.

    Reason two says they’re inefficient, but the reality is that the speed of our code running isn’t the speed developers should be concerned with first and foremost. Smart developers are more concerned with how they can be efficient as developers (how efficiently they can write the code), and ORMs are certainly a better solution for being efficient as a code writer. Premature optimization is one of the worst mistakes a developer can make, choosing to avoid a tool because you’re afraid it might be slow can cost you countless hours for no benefit at all.

    And for reason three, yes an ORM can’t do everything, but it can do everything that the majority of developers will ever need it two. It is foolish to avoid a tool because you think it can’t do something that you never actually.

    This is such a joke, the fact that this article is the first result in google when searching “Node ORM” completely insane. It’s so ridiculously misleading, not only because the three reasons aren’t really valid to most developers, but for the simple fact that you’re misleading developers on how they should be choosing their tools and misleading them to worry about things that don’t matter most of the time.

    Making your code efficient is not nearly as important as being efficient while making your code (in most cases). Avoiding tools because they don’t have a feature that you’ll never need is illogical. AND FOR GODS SAKES ORMS ARE NOT HARDER TO USE THAN DIRECT DATABASE INTERACTION (for most people). This is such a shallow, one sided article, and it triggers me.

    1. There are some good points here but the fundamental premise of your argument seems to be that most developers will never need to do anything an ORM can’t do. You’ve said a version of that repeatedly in your comment. I think this is your own bias.

      Some people are fluent in SQL before they ever touch an ORM and those people will be acutely aware of the points made in this article. In the inverse, someone who is comfortable doing ordinary things with an ORM is immediately thrown in the deep end of the underlying query language when they have to do something a little out of the ordinary. In my experience there’s a point where ORMs become more verbose or convoluted than the underlying SQL and that point is often immediately beyond the mundane.

      Furthermore, you misunderstand the implications of point number two. If you’re using a frontend framework like React or Vue, you often want a subset of data to send to the browser. The SELECT statement from the ORM is returning a bunch of extraneous data so unless you want to unnecessarily send it all to the browser you must prune it. So it’s not just a matter of prematurely optimizing, it’s the fact that the ORM is giving you data you don’t want which you have to deal with in code.

      Maybe you’ve never found a need to do something that the ORM can’t do but what makes you think you’re in the majority? Maybe you don’t have experience with this topic but maybe many people do and it resonates with them and that’s why it ranks so high with the search engine

    2. I don’t remember ever feeling the urge to give in to comments, but this takes the cake and I can’t resist. I have to state right away, that I’ve been coding for over 30 years with the last 15 mostly in web-dev. This article is extremely important, and possibly much more than anyone can realize. I admit that I’m old-school and prefer doing everything myself (but this also stems from the type of projects I worked on, in which 3rd-party modules aren’t permitted) but nonetheless, introducing an ORM of any sort is abstraction. Going by good software-engineering practices, abstraction can never be a positive approach, be it in imperative or declarative paradigms. On the other hand, in projects that had unrealistic deadlines and weren’t tied with no 3rd-party constraints, I’ve used Knex on Node, and, its abstraction layer (if used correctly) can be close to negligible for performance tests & query optimization. If you start off by disregarding the queries costs, you’re asking for trouble, or, you’re not proud of the work you produce. And oh, last thing, if my response is equally condescending, it’s cause it stems from the educator in me (as in the past 5 years I’ve shared my knowledge with hundreds of CS & General Programming students in several colleges in the US and Europe), which riles me up to see such attitude!!

      1. Not to disparage your experience, but “abstractions never being a positive approach” is just plain silly. It’s abstractions that allow us to create hugely complex solutions in a reasonable time in the first place.

        Everything you are using today is working on tons of layers of abstractions, from your BIOS through your OS and the applications on it. Why are you even developing in NodeJS when you could be writing assembly or even better, just inputting 1s and 0s through some morse-code like device instead of a keyboard?

        This is completely tangential to the ORM discussion, there are pros and cons to using one and you should look at your use case to figure out if the pain is worth the gain. Blanket statements and oversimplifications don’t help.

        1. I was going to write a similar response to this. Even rust and c are abstractions. I learned this in my first high school programming class. Anyone with an opinion against abstractions is misguided. Everything we do in coding is creating abstractions. Think about it!

        2. I think he’s talking about “abstraction for its own sake”. Abstraction makes sense in many cases, leads to scaleability, cleaner code and often looser coupling of artifacts.
          But, thinking about ORMs as the possibility to relieve you from learning SQL – this is no needed abstraction. The code don’t look better, the performance of the software won’t get better and you have more dependencies.

          I just use a simple code generator to generate the data Objects from the database definition with some often used CRUD functions to persist and retrieve the data. When i need some more complex SQL statements, I just add them in the code to the generated functions.
          I think, this approach is fast, because 90% of the code is generated, it’s light weight and the code is clear.

  3. Dude you’re being super condescending. You should read this out loud, is that the way you would talk with someone in person, or is this just internet tough guy taking a stance on… ORMs… If you can’t read a blog post about something this low stakes without talking down to someone, maybe you considering avoiding things that trigger you so much.

  4. Hi,
    There is little research on which technique is faster. Intuitively, Raw SQL should be faster than Eloquent ORM, but exactly how much faster needs to be researched. In particular, when one uses Raw SQL over Eloquent ORM, one makes a trade-off between ease of development, and performance. Will you write some content on it for my understanding .

  5. It’s true! ORM (object-relational mapping) doesn’t fit to the current needs of coding. And when it comes to Node.js ORMs, things get complicated and needs simplified solution. Therefore, i find this article good in this case.

  6. Yes, it is correct! ORM (object-relational mapping) does not meet today’s coding requirements. And when it comes to Node.js ORMs, things get a little more involved, necessitating a more straightforward approach. As a result, I believe this post is appropriate in this situation.

  7. I like how awesome ORMs can be but after trying to use PrismaJS and right from the start run into bugs that have already been reported by other users made me turn back on the choice to use one. When getting started with a ORM provides a smooth path to application development (like Mongoose), its great. But when it’s not smooth, it doesn’t seem like it’s worth the time to fight with the ORM (or go looking for others) instead of just writing raw queries.

  8. Very useful article thank you! For someone new to database access in Node generally, this is a great survey of the different options for doing so and some valid critiques on each.

    I would add that the argument would be much weaker if the Node ORM space was more mature. (Maybe this is because so much Node development just defaults to MongoDB – which is a topic for a post all of its own!) The best ORM I have worked with is Django’s. It is extremely capable at constructing complex queries, including injecting aggregates, subqueries, and the like, and in the last few years I’ve not needed to resort to plain SQL to generate optimal queries. The main advantage of this is isolation from the schema details – much can be done to the schema without requiring code changes elsewhere. Another is use of the schema definitions in, for example, automatically generating REST APIs, HTML forms, test data generation, and so on, with code that is completely generic to model. One tiny point relevant to the above, is an expertly written ORM can be more efficient than an average, hand crafted one, particularly at populating objects (although granted this is more the case for strongly typed languages). One final notable one is migrations. Gone are the days of having to maintain both the current schema, and incremental version update scripts. If the Node ecosystem ever gets an ORM offering these, without the performance compromises of Sails+Waterline you mention, (with luck), this article could need revising.

  9. I typed “node js orm” and landed here. It isn’t what I was looking but it is what I need. The article made marvelous work trying to convince why to choose query builder instead of orm.
    I’m glad I read it, it helped me make my mind. I found it really practical to query only exactly what I want. Also I read a bit comments, and I think most of them miss the point, why JS developers pick ORM in first place. Nodejs is specific tool, often chosen by FE developers that have limited knowledge about databases.
    ORM allow developers to use db not knowing it. I think this article is solid to explain why it worth to learn database, not ORM.

  10. I am using Sequelize at the moment and it is a learning curve coming from using JPA on Java. It is quite different in the way it lazy fetches relationships and I cannot figure out how to create an @OrderColumn. But going back to pure SQL queries seems like a step backwards. You have to understand how the ORM works in order to avoid big queries

  11. This is a wildly cold take. some ORMs are better than others, but a good ORM and knowledge of how to use it correctly can make your code much more sustainable long term, not to mention making your application as a whole more DRY.

    If your main selling point is “learn SQL over an ORM” then your issue is your existing knowledge, not the ORM.

    ORMs don’t do everything for you, but as always an application has a million little pieces and an ORM is a very important piece of the puzzle.

  12. Yes, I agree. Many people use ORM wrong way – as a silver bullet for everything. The core task of ORM is to let the programmer write SQL queries by hand and map the result to object(s). Many people forget it – no automatic queries building, no relationship. Then, the second core task is to do simple CRUD. Very useful is, if ORM support queries with named parameters. And that’s enough to have a good ORM. See C# Dapper ORM! (Is there any JS ORM like Dapper?)

    All other stuff – query builder, relations ships, etc. use very cautiously. Even Gavin King, authot of the famous Java Hibernate ORM said, that ORM is to do 50-90% of your tedious work, never try to use it for everything.

  13. Whenever I see someone talk about performance without providing actual benchmarks, I know they are talking nonsense. The difference in raw vs generated SQL could be minimal, and it would not matter anyway in most cases — unless you are working on an e-commerce website or writing a server that handles 30K requests per second, performance is likely not the first thing you need to worry about.

  14. What a load of bollocks. Any decent ORM will create queries just fine and their speed of execution will be just fine also. Your FUD serves no purpose apart from pushing your own bias on unsuspecting new developers.
    Saving a few milliseconds here and there on the occasional query does not make up for the tedium of writing extended queries or the costs associated with supporting that software. I’ve written applications without ORM assistance in the past and I can only imagine the curses I’m receiving from the staff who have to maintain the hand written SQL now.
    If there’s a really curly query that can’t be performed by an ORM, they’ll all provide the ability to write raw SQL, so there’s really no need to ever not use an ORM. The only thing I can think of is if you want to be a hero who shows off that he can write his own SQL using less characters than the ORM does.
    If you personally want to continue writing your own SQL, by all means do so, but please stop poisoning the minds of new developers who are going to read your article (because somehow it’s one of the first results for “node orm”) and think that it’s somehow best practice.
    You should be ashamed of yourself.

Leave a Reply