I get it. ORM’s are great. They make your life easier. For projects that are time sensitive or even have budget constraints maybe an ORM framework/library can help speed up that process a bit and help you deliver that project on time and within budget. On the other hand, for personal growth and personal projects, I would recommend dropping an ORM and writing SQL queries instead.

What is an ORM?

Ok, you probably know what it is but for SEO reasons I am just going to explain this. An ORM is an Object Relational Mapping. It is a programming technique for converting data between incompatible type systems in object-oriented programming languages. It is a way to interact with a database using objects instead of writing SQL. (I literally just let AI write that part).

The human readable version is that it is a library or framework that gives you an opinionated way to interact with the database. You get a set of predefined methods that make updates, inserts, deletes and queries easier to write and understand. You can also get type safe results and possibly help you avoid SQL injection attacks (if you are not well versed in that area).

Most of the popular ORM’s provide some tools out of the box like migration and database versioning which can be very helpful.

Some ORM’s can make switching your database from one RDMS to another very simple. For example, if you are using MySQL and you want to switch to Postgres, you can do so with minimal changes to your code. Hell you can even pull this off with a NoSQL database like MongoDB. That is a pretty powerful feature. However, I have never come across a scenario where I wanted to switch my database. So its a feature I have never even wanted let alone used.

What are the cons of an ORM?

Well, it kind of depends on the ORM but a common set of issues resolve around performance, too much abstraction, lack of control (although most allow you to write raw SQL to gain that control back) and the learning curve.

Lets go over each one of those.

Con 1: Performance

Some ORM’s are not as performant as writing raw SQL. Since their goal is to generalize most of what you want they can often generate queries that are not as efficient as they should be. This is not always the case but it is something to be aware of. One example is with PrismaJS. PrismaJS tends to have a problem with adding joins. In many cases where a simple join is needed, Prisma will make multiple queries to the database instead of one. This can be a problem if you are not aware of it and can lead to performance issues if your application requires many queries that require joins. ORM’s can’t assume the best way to write a query and can’t optimize for the best performance for every scenario. They are best suited for simple and common tasks.

Con 2: Abstraction

The level of abstraction can be an ORM’s greatest strength while also being its biggest weakness. Sometimes you just don’t know what the hell an ORM is doing back there. Like in the previous section, you would think running some query to join two tables together would, in fact, use a join. I have had other issues where something felt so clear in its methods but would return unexpected results. Some ORM’s don’t even support all of the features of SQL. You may find yourself having to write raw SQL anyways to get a specific job done.

Con 3: The Learning Curve

ORM’s may be easy to pick up at the start but that time spent learning them is only useful if the projects you work on afterwards, also use that same ORM. Imagine this: You spend a few weeks learning PrismaJS (This story sounds like it may be true) and then you get a job that uses Sequelize. All that time learning PrismaJS doesn’t really help out that much. I mean there are some similarities but not much. Even worse, you have to jump on another project that also has a backend in PHP or Go. Maybe PHP uses an ORM but if it does, its another thing you may need to learn. Or, what if its not an ORM at all? What if its just raw SQL? Now you are just forced to use SQL anyways.

Con 4: Lack of Control

We’ve gone over inefficient queries that an ORM can generate but often, ORM’s allow you to write raw SQL to get around that barrier. However, there is another issue lurking in the shadows and that is another dependency on third party developers to provide fixes to potential issues an ORM may have. Nothing is worse than finding a bug in an ORM and having to wait for a fix. This is always a scary situation to be in when you have an application in production serving tons of customers.

Language and Framework Agnostic Tools

I mentioned earlier that one of the benefits of ORM’s is the tooling you get out of the box. There is no tooling that your ORM gives you that you can’t get elsewhere. For example, database versioning and migrations for PrismaJS are a breeze. Don’t get me wrong its amazing. However, you could just use a tool like Atlas to do much of the same thing. You are not restricted to a particular language or framework on the backend. As long as you are using a RDMS, you can use other tools that do as good or better of a job.

Why you should just learn SQL instead

At the end of the day, you just can’t avoid it with a RDMS. At some point you will find yourself searching for the “Raw SQL” method in your favorite ORM to write that one query that is becoming a bottleneck in your application.

This is not to say that you shouldn’t use an ORM, although I tend to prefer not to use them. You should, however, understand how to write SQL so you can understand better if your ORM is actually making your life easier or more difficult.