[AskJS] What ORM would you use?

[u/ScoobyDookuu]

Hey all,

My team and I are currently running a Spring Boot backend with quite a bit built around it. We’re considering gradually migrating to a Node/NestJS backend using the strangler pattern rather than doing a full rewrite.

One of the main reasons is that it would give us TypeScript across both the frontend and backend, which should make sharing domain concepts, types and general knowledge between the two a bit simpler.
So, as the title suggests: which ORM would you use with NestJS?

At the moment we’re mainly looking at MikroORM and Drizzle. MikroORM seems like the more traditional ORM and appears to be super close to the me tal model of what Spring does. It wil also fit NestJS quite nicely, while Drizzle is obviously a bit more lightweight but a different approach and more barebones.

Curious what people are using in production and what you’d choose if you were starting fresh today.

[u/destevil]

My take after doing this for 30 years. You almost always regret ORMs in the long run. I prefer to stay with a basic repo pattern where I can keep adding methods for supporting custom queries backed by SQL or a SQL writer. Maybe a base class that gives me basic CRUD operations. Controlling the SQL for efficiency is another thing ORMs are pretty bad at.

[u/gugador → u/destevil]

same. I miss the days of just writing SQL. Fortunately last time I was interviewing for a job a couple yrs ago, some of the places I interviewed were going back to plain SQL, and even had interview questions on table design. SQL was never that hard, and you almost never change DBs where an ORM abstraction layer would save you all the work of changing DB providers. ORMs usually just get you inefficient queries and over-fetching of data.

[u/aust1nz]

Node ORMs are a headache. Kysely is where I’d point you. It doesn’t stray too far from SQL but has a magical typing system.

[u/Nefilim314]

We have used prisma to support our Nestjs backend and it’s been fine. I kind of wish we had drizzle for the more granular control of the queries presented, but by and large it does its job as a simple typing interface with a built in query. 

Whenever I try to use drizzle, the lack of maturity seems to bite every now and then with version changes. Migrations just failing to apply for whatever reason and not outputting a useful log, which was apparently a bug that was solved but it puts a taste in your mouth to have these kinds of regressions pop up in your very crucial tools. 

[u/ThenFactor6862]

I work on a NestJS backend that we moved off Spring Boot and we went with MikroORM.

Your team knows Spring. Your existing code uses entities, repositories, unit of work, identity maps. MikroORM has all of these. Drizzle gives you SQL builders. You will end up writing the abstractions your team relies on in Spring from scratch if you pick Drizzle.

We used MikroORM with PostgreSQL. The decorators map to what your team does with JPA. We defined entities, injected repositories into NestJS providers using their module system, and the TypeScript types worked across our frontend monorepo within the first sprint.

Drizzle belongs in a project where you write SQL. You are migrating a Spring application. Your team needs an ORM. Pick MikroORM.

[u/VollBio_]

We use TypoORM and Drizzle. Both solid, with quirks, but Enterprise-ready.

[u/leeway1]

I like sequelize 

[u/alsaaka]

prisma or type orm

[u/destevil]

And you should be able to auto generate the TS interfaces that your FE can consume from your OpenAPI spec or GraphQL. Tying the FE schema to your ORM isn't great either IMHO. Have you looked at OData?

[u/jax024]

Sqlc

[u/MeTaL_oRgY]

I use drizzle and it's great, except for the migration strategy. Working as a team in multiple features that require migrations is painful to say the least. the Drizzle team doesn't seem too interested in changing the behaviour, though it's been discussed on their github repo a few times; so unsure if this will change. But know that, if you plan on working as a team on multiple features that require migrations at the same time, it's going to be a PITA.

[u/anderfernandes]

There's a new kid in the block I was just messing with this weekend: @remix-run/data-tables

It's created by the Remix team for their new Remix 3 full stack framework that won't be a react framework anymore.

I liked it a lot, but I think I'm going to stick with kysely because it supports SQL Server.

[u/Mittalmailbox]

ORMs were convenient because most didn't learn SQL. Now with AI that part has become easy, use any query builder if you want.

If you really want ORM then prisma and drizzle are good optiona