To ORM or not to ORM (that's the question)

Exploring both DBA's and programmers point-of-view

ORMs (Object-to-Relational Mapping) are a must for programmers, while they are usually a nightmare for DBAs. At the same time, they are large and complex, and underpowered -compared to the database itself-. It's time to rethink ORMs, and let programmers receive input from the database community in a new strategy of collaboration where a new interface (say "API") between both is designed.

Recently, ORMs (Object-to-Relational Mapping) are becoming controversial. Most programmers can't simply live without them, and argue that handwritten SQL is cumbersome and error-prone. On the other hand, DBAs cry about the terrible performance and inefficiencies they may induce in the database. Even some programmers state that ORMs are not able to fully exploit the power of the database.

Worse, most ORMs are becoming increasingly large and complex, yet they fail to deliver (at least at the ORM abstraction level) what may be considered as basic to intermediate db capabilities, such as triggers, roles or table constraints. This failure of ORMs is also eroding databases' prestige, what in turn feeds a growing community that is advocating for eliminating SQL altogether.

So, who's right? What is the future of ORMs? How should them evolve, if not disappear?

We don't need to rethink the SQL-relational model --it simply works. What we need to rethink is the DBA-programmers interface (as if it were an API) so that ORMs may fully work.

Time is running fast. We have to react. This talk may be best viewed as a call for collaboration between DBAs and programmers. It's a starting point to re-think ORMs and help save the SQL-relational world!

(And the PostgreSQL community should have a lot to say about this, so let's do it!)