Prisma, Eloquent, Doctrine: why use ORMs?

As developers working on the backend, we have a problem. In the programming world, the default way of modelling reality is by using Object-Oriented programming.

However, the default standard for modelling data in a database is by using tables. Those two, Objects, and Table rows, are not directly compatible in terms of our mental model. There is a gap.

And this is where ORMs like Prisma, Doctrine, Active Record or Laravel’s Eloquent come into play. They help bridge the gap between two mental models: tabular data and object-oriented programming.

ORMs map data between objects and databases. Hence, the name: ORM means Object-Relational Mapping.

They make life so much easier. However, that is not without drawbacks. We’ll get to that later. But first, what are ORM’s main advantages?

First, ORMs allow you to interact with databases using a syntax you are familiar with. It makes developing a lot easier.

This conversion abstracts away the subtleties of working with the database, providing the second advantage: It removes a whole load of boilerplate code.

That brings us to the third advantage: Less code means less maintenance and fewer bugs. It means code that is easier to read. It means a better developer experience all around. Less code makes life easier for everyone.

Fourthly, in some cases (such as Prisma) an ORM can allow you to have a shared interface that abstracts away the implementation details of the underlying database. You tell it what you want to get, and it worries about how to get it.

However… that level of abstraction, of indirection, comes at a cost. I count 5 points to watch out for.

First, ORMs can introduce performance overhead because they need to translate between the database and the programming language.

Second, ORMs can hide important details about the underlying database, which can lead to unexpected behaviour or performance issues. If you don’t know exactly what the ORM is doing, optimising how you use it is difficult.

Third, ORMs are often less flexible than accessing the underlying database. This can also mean that you are less able to optimise how you query the database. Because you don’t have the flexibility to specify precisely what you need the generated query to look like.

Fourth, ORMs introduce maintenance overhead. They need to be updated regularly to keep track of new features in the underlying database technology.

Fifth, ORMs add complexity to an application. They require an in-depth understanding of the ORM's behaviour and limitations. This can actually make it more difficult to debug and optimise.

It's essential to carefully consider the specific requirements of a project before deciding to use an ORM, and to be mindful of the potential limitations and trade-offs.

Now, what does this mean? Should we shy away from ORMs because of this?

No. Despite these pitfalls, ORMs are still valuable tools for many applications and can greatly simplify development. In most cases, the ORM is your friend.

However… it’s important to understand what the drawbacks are. You need to understand what it is doing behind the scenes to get the most out of your ORM. What behaviours it is introducing. What queries it is generating.

Understanding how your ORM works is vital for the long-term success of what you are developing.