I’ve worked with a few ORMs in small to medium-large sized projects: Doctrine, Sequelize, Bookshelf, Objection, Entity Framework…

With that said, it’s been a while since I’ve considered essential to have an ORM when bootstraping a project. I rather create my own data layer.


  • ORMs are cute for CRUD operations, but when things get slightly more complex you find yourself having to learn the ORM’s way of working, spending time disecting its (possibly not great) documentation, searching Google for specific ORM related problems your facing, and so on…
  • ORMs are quite different from one another. You’ll eventually end up in a project that uses a ORM with which you’re not so familiar with. And possibly after that you’ll start a project yourself and you’re going to want to try yet a new ORM. On the other hand, SQL is a standard. Despite DBMSs being different and having distinct SQL language implementations, most of them will have similar concepts and SQL will be close to the standard. Since I studied DBMSs to some extend, I’ve been able to comfortably jump between MySQL, PostgreSQL, MS SQL Server and others.
  • You’ll always get better performance from raw SQL queries. An ORM needs to parse the arguments and objects you pass into some query function, build the query accordingly, replace variables, run the query, assign results into your models and its relations, etc.

But, but…

  • “I don’t know SQL and this way I don’t have to learn it”. Nice. Good luck debugging the often messed up queries generated by the ORM. Good luck finding out why certain query is dragging its tail. Good luck figuring out how to build a not so obvious query.
  • “By using an ORM I’ll be able to change DB with minimal to none code changes”. I actually “believed” in this argument as well. Be realistic: this is never going to happen. If you’re going to change DB in a project that is up and running, ORM or not, you’re in for a treat.

With that said, nothing against ORMs (really). I do believe they have their place.

But go and learn SQL!!!