I've shipped all three in NestJS. Here's how they actually compare on DX, migrations, generated SQL, and transactions, and which one I reach for now.
OK so a late-evening deploy at the creator-economy platform I worked at went sideways because a Rails migration grabbed an ACCESS EXCLUSIVE lock on the users table and sat on it for 87 seconds. Logins fell over at peak Pacific hours. That was Rails and ActiveRecord, not NestJS, but the lesson rerouted how I think about ORMs everywhere else. Migrations are the part that bites you. Query DX is the part that wastes your time. Both matter, and the three NestJS ORMs everyone reaches for handle them very differently.
I’ve shipped TypeORM, Prisma, and MikroORM in production NestJS services. Different scales, different teams, different pain. Here’s the comparison I wish I’d had when I started.
My short answer: MikroORM is the one I keep coming back to for serious work. Prisma is the one I reach for when the team is fresh and the schema is shallow. TypeORM is the one I’d inherit and not pick again.
TypeORM started as the obvious choice because NestJS docs lean on it. It has decorators, it has repositories, it speaks the same dialect as the rest of NestJS. That’s where the good ends. The internals are inconsistent. Relations behave differently depending on which API you used to load them. The query builder and the active record style fight each other. Migration generation produces SQL that I’ve manually rewritten more often than not.
Prisma went the other direction. Schema-first. A generated client. Type safety that genuinely catches mistakes at compile time. The DX on a green-field NestJS project is the best of the three. Two weeks in, you’re flying. The wall comes later, when you need a recursive CTE, a partial index, a check constraint, or a transaction with proper isolation level. Prisma has answers for most of these now, but they live outside the elegant happy path.
MikroORM is the one nobody talks about enough. It’s a true unit-of-work ORM, modeled on Doctrine and Hibernate. Identity map, change tracking, explicit flushes. Entities are real objects, not anemic DTOs. Migrations are predictable. The query builder is honest about what it produces. The learning curve is steeper than Prisma. Past it, the productivity is the best of the three.
import {
Entity,
PrimaryGeneratedColumn,
Column,
ManyToOne,
Index,
CreateDateColumn,
} from 'typeorm';
import { Creator } from './creator.entity';
@Entity('subscriptions')
@Index('idx_subscriptions_creator_status', ['creator', 'status'])
export class Subscription {
@PrimaryGeneratedColumn('uuid')
id!: string;
@ManyToOne(() => Creator, (c) => c.subscriptions, { nullable: false })
creator!: Creator;
@Column({ type: 'varchar', length: 32 })
status!: 'active' | 'paused' | 'canceled';
@Column({ type: 'jsonb', default: {} })
metadata!: Record<string, unknown>;
@CreateDateColumn({ type: 'timestamptz' })
createdAt!: Date;
}Looks fine. Then you write a service that loads a subscription with findOne({ where: { id } }) and silently gets a partial object because relations: ['creator'] wasn’t set. The compiler is happy. Runtime hits subscription.creator.id and throws. TypeORM gives you a stack trace that points nowhere useful. I’ve debugged this exact thing on three different teams.
model Subscription {
id String @id @default(uuid())
creator Creator @relation(fields: [creatorId], references: [id])
creatorId String
status SubscriptionStatus
metadata Json @default("{}")
createdAt DateTime @default(now())
@@index([creatorId, status])
}
enum SubscriptionStatus {
active
paused
canceled
}The generated client is the win. prisma.subscription.findUnique({ where: { id }, include: { creator: true } }) returns a fully-typed object including the relation. No surprise partials. The schema file is the single source of truth, and migrations are diffed against it. For a small NestJS app with a fresh team, this is the fastest path to shipping I know.
Then your product needs a partitioned table, a materialized view, a LATERAL join, or a row-level security policy. Prisma’s answer is prisma db execute and $queryRaw. Both work. Neither is typed. You’ve stepped out of the Prisma world and into raw SQL stitched to a TypeScript codebase. The escape hatch is fine. It’s the frequency at which you have to use it that decides whether Prisma fits.
import {
Entity,
PrimaryKey,
Property,
ManyToOne,
Enum,
Index,
Unique,
} from '@mikro-orm/core';
import { v4 } from 'uuid';
import { Creator } from './creator.entity';
@Entity({ tableName: 'subscriptions' })
@Index({ properties: ['creator', 'status'] })
export class Subscription {
@PrimaryKey()
id: string = v4();
@ManyToOne(() => Creator, { nullable: false })
creator!: Creator;
@Enum({ items: ['active', 'paused', 'canceled'] })
status!: 'active' | 'paused' | 'canceled';
@Property({ type: 'jsonb' })
metadata: Record<string, unknown> = {};
@Property({ type: 'timestamptz' })
createdAt: Date = new Date();
@Property({ persist: false })
@Unique()
externalRef?: string;
}Looks similar. The difference shows up in the EntityManager. MikroORM tracks every loaded entity in an identity map, watches for changes, and emits a single flush() that batches inserts and updates inside a single transaction. You stop writing await repo.save(x) after every mutation. You write the business logic, then flush once.
import { Injectable } from '@nestjs/common';
import { EntityManager } from '@mikro-orm/postgresql';
import { Subscription } from './subscription.entity';
@Injectable()
export class CancelExpiredSubscriptionsService {
constructor(private readonly em: EntityManager) {}
async run(now: Date): Promise<number> {
const expired = await this.em.find(
Subscription,
{ status: 'active', expiresAt: { $lt: now } },
{ limit: 500, orderBy: { expiresAt: 'asc' } },
);
for (const sub of expired) {
sub.status = 'canceled';
sub.metadata = { ...sub.metadata, canceledReason: 'expired' };
}
await this.em.flush();
return expired.length;
}
}One transaction. One round trip to commit. Predictable SQL. No save calls scattered through the method. That’s the unit-of-work pattern doing what it was designed to do.
Here’s the part I weigh most. Schema migrations are the operational risk surface. A bad migration is a real outage.
What I want from a migration tool: predictability, reviewability, and SQL I can read. TypeORM’s migration:generate produces SQL I have edited by hand on every project I’ve used it on. Prisma’s migrate dev is excellent for local iteration, but migrate deploy against a production Aurora cluster with >10M rows is the same dance regardless of ORM. You still have to write the three-step migration yourself. MikroORM’s migration generator is the closest to “what I would have written by hand”, and it integrates with the unit-of-work cleanly so a migration plus a backfill job lives in the same module without ceremony.
None of the three saves you from understanding Aurora’s locking model. They differ in how much they pretend to.
If your ORM gives you easy read-after-write that silently routes the read to a replica, you will eat replica lag in production. TypeORM has reader/writer routing through master/slave connection options. Prisma has read replicas via an extension. MikroORM lets you bind a transaction to a specific connection so the read inside the transaction always hits the writer. The third option is the one I want.
await this.em.transactional(async (em) => {
const order = em.create(Order, { userId, total });
em.persist(order);
await em.flush();
const fresh = await em.findOneOrFail(Order, { id: order.id });
return fresh;
});The fresh read inside the same transactional block sees the write because MikroORM keeps the transaction pinned to the writer connection. That’s not a feature you appreciate until you’ve watched a read replica disagree with itself.
If the team is new to NestJS and the schema is simple, pick Prisma. The DX wins matter more than the SQL ceiling for the first six to nine months. Just budget for the day you have to drop into $queryRaw.
If the team will live with this schema for years and the data model has depth, pick MikroORM. The identity map and the unit of work pay for the steeper ramp many times over. The generated SQL is honest. Migrations are reviewable.
TypeORM is the one I’d inherit, maintain, and replace at the first reasonable opportunity.
Thanks for reading. If you’ve got thoughts, send them my way.