I have shipped backend code on TypeScript stacks for about four years now, and the question that keeps coming back from junior engineers we onboard at Warung Digital Teknologi is always the same one: which ORM should I pick? In 2026 that question is louder than ever. Prisma rewrote its query engine. Drizzle hit 32k stars. Kysely quietly became the secret weapon for serverless edge code. TypeORM is still everywhere in legacy NestJS apps and refuses to die.
This article is the comparison I wish someone had handed me back in 2022 when I was wiring my first Prisma schema for a hotel management dashboard and watched the cold start nearly kill our serverless deploy. I have since used Drizzle in production for the daily aggregator imports across our seven content sites, fought with TypeORM on a NestJS payroll app, and rewrote a Kysely layer for our internal helpdesk tool when raw SQL control finally mattered more than developer comfort.
So here is the honest breakdown. No vendor talking points, no "every tool has its place" cop-out. Just what I would pick today for specific situations, and why.
The 30-Second Answer If You Are In A Hurry
- Greenfield Next.js or full-stack TypeScript app, team includes juniors → Prisma 7
- Edge runtime, Cloudflare Workers, Vercel Edge functions, bundle size matters → Drizzle
- You write SQL fluently and want type safety without abstraction → Kysely
- Inheriting a NestJS codebase that already uses it → TypeORM (do not migrate just because)
- Heavy raw SQL queries with complex joins, CTEs, window functions → Kysely or Drizzle
- Multi-database support across Postgres, MySQL, SQLite without rewriting → Drizzle
If you want the reasoning behind each of these calls, keep reading. I tested all four on a real workload — importing roughly 200 records per day per site across our blog network — so the numbers below are not borrowed from someone else's benchmark.
What Changed In 2026 That Reshuffled The Rankings
The TypeScript ORM landscape was relatively stable from 2023 through early 2025. Then four things happened in quick succession that you need to understand before you pick:
Prisma 7 dropped the Rust query engine. The old Prisma binary was around 16MB and shipped a separate Rust process that talked to your database. That worked fine on a long-running Node server but was brutal on serverless cold starts — on our Vercel deploys we measured cold starts north of 1.2 seconds when the Prisma engine had to spin up. Prisma 7 ships a TypeScript and WebAssembly query compiler instead. The bundle is now around 600KB gzipped. Cold starts on the same Vercel function dropped to about 180ms in our testing.
Drizzle hit production maturity. Drizzle was the new kid in 2023 with maybe 4k stars. As of the last time I checked the repo before writing this, it sits around 32k stars with roughly 900k weekly npm downloads. Big shops including Vercel internal teams use it now. The relational query API filled the last gap that made it feel half-finished.
Kysely got pgvector and JSONB helpers. Kysely was always elegant for people who write SQL well, but missing helpers for Postgres-specific features made it a slog if you used JSON columns or vector search heavily. Plugin authors filled those gaps in late 2025.
TypeORM lost its lead maintainer for a stretch. The repo went quiet for several months in 2024, raising legitimate fear that it was abandoned. Maintenance picked back up but momentum is clearly with Drizzle and Prisma now. TypeORM has not had a major architectural improvement in a long time.
Those four shifts are the reason most of the comparison articles you read from 2023 are basically wrong now. I caught myself recommending Prisma against Drizzle on bundle-size grounds well into 2025 because I was working off the old 16MB number. Lesson learned: ORM benchmarks decay fast, and you need to re-test before pitching a tech choice to a client.
Prisma 7: Still The Default Recommendation For Mixed Teams
Prisma is the ORM I reach for first when a client team has a mix of experience levels. The schema-first design is genuinely productive once you internalize it. You write your data model in schema.prisma, run prisma generate, and you get a typed client out the other end. The migrations workflow with prisma migrate dev is the smoothest of any ORM I have used — it generates SQL files, applies them, and keeps a shadow database for safety checks.
What Prisma 7 Got Right
The new query compiler is the headline feature. On the helpdesk app I rebuilt for an internal client last quarter, our cold start times on Vercel went from a measured 1,180ms median (Prisma 5) to 178ms (Prisma 7) for the same query payload. That is an 84% reduction. For a B2B SaaS where the dashboard is hit sporadically, this is the difference between "feels fast" and "feels broken."
The other thing I appreciate is how stable the ergonomics are. Prisma's API has not had a breaking redesign since 2.0. If you onboarded an engineer in 2023, they can pair with one onboarded in 2026 without confusion. That matters more than benchmarks for a team that has to maintain code for years.
Where Prisma Still Hurts
Two real complaints. First, the abstraction sometimes hides expensive queries. Prisma's include for nested relations can generate N+1 queries or one giant join, depending on the version and the relation type. I have caught this twice in production by enabling query logging and seeing 14 queries fire for what looked like a single .findMany() with two includes. You can fix it by switching to prisma.$queryRaw or refactoring with explicit selects, but you have to know to look.
Second, raw SQL escape hatches feel awkward. prisma.$queryRaw works but you lose the schema-aware type inference. For complex reporting queries our analytics team writes, Prisma is the wrong tool — we drop down to a different layer for those. That mental context-switch is a tax on the codebase.
My current rule: Prisma if your queries are CRUD plus a few aggregations. Move to Drizzle or Kysely if more than 20% of your code is raw SQL.
Drizzle: The One I Use Most In 2026
Drizzle is what I would call my current default, and that switch happened in mid-2025 when I rebuilt the blog import pipeline that handles daily article ingestion across our seven aggregator sites. The pipeline runs on Hostinger shared hosting through a Node process kicked off by cron. Bundle size matters because we have memory ceilings, and cold starts on the cron worker matter because the import has a 20-minute window before the next run.
The Code-First API Clicks If You Like SQL
Drizzle inverts Prisma's schema-first approach. You define your tables as TypeScript objects:
export const articles = pgTable('articles', {
id: serial('id').primaryKey(),
title: varchar('title', { length: 255 }),
slug: varchar('slug', { length: 255 }).unique(),
content: text('content'),
publishedAt: timestamp('published_at'),
});Queries read like SQL with autocomplete. db.select().from(articles).where(eq(articles.slug, 'foo')) is exactly the SQL you would write, just with type safety bolted on. There is no opaque query builder magic, no second mental model to learn. If you can read SQL, you can read Drizzle.
The Numbers I Measured
On the import pipeline I mentioned, I ran the same workload (insert 187 articles, dedupe by slug, update featured-image paths) on three configurations: Prisma 6, Prisma 7, and Drizzle. Average wall-clock time across 12 runs each:
- Prisma 6: 4,830ms average
- Prisma 7: 3,420ms average
- Drizzle: 2,940ms average
The 14% gap between Prisma 7 and Drizzle is small enough that it would not drive a decision on its own. The bundle-size gap is what mattered for me — Drizzle's 7.4KB gzipped versus Prisma 7's 600KB gzipped meant I could deploy the import worker as a Cloudflare Worker if I ever wanted to, which I have already done for one site.
Where Drizzle Annoys Me
Migrations. Drizzle Kit generates SQL migrations from schema diffs, and the diffing logic has caught me out twice when I renamed a column. Drizzle Kit reads it as "drop old column, create new column" and you lose data unless you manually edit the migration. I now always read every generated migration before running it, which I should be doing anyway, but it is more defensive than what Prisma forces.
The other gripe is documentation. Drizzle's docs are improving but still scattered — some patterns only show up in GitHub issues or Discord answers. For a junior engineer figuring out a complex relational query for the first time, Prisma's docs are noticeably more handholding.
Kysely: The Power Tool For SQL-Fluent Teams
Kysely is not really an ORM. It is a typed SQL query builder, which is a meaningful distinction. There is no schema-to-code generation. There is no migration tool included by default (you bring your own, or use Kysely's kysely-migration companion). What you get is a type-safe DSL that maps almost one-to-one to SQL syntax, with the database schema declared in TypeScript types.
When Kysely Is The Right Call
I rewrote a chunk of our internal helpdesk ticketing system on Kysely last year because the reporting queries had grown into territory Prisma could not represent cleanly. Window functions, CTEs, JSON aggregation across nested objects — the kind of analytical SQL that exists in many real B2B apps once they have been in production for a while.
Here is what a Kysely query looks like for a ticket-aging report:
const aging = await db
.selectFrom('tickets')
.leftJoin('users', 'tickets.assigned_to', 'users.id')
.select([
'tickets.priority',
sql<number>`COUNT(*)`.as('total'),
sql<number>`AVG(EXTRACT(EPOCH FROM (NOW() - tickets.created_at)))`.as('avg_age_seconds')
])
.where('tickets.status', '=', 'open')
.groupBy('tickets.priority')
.execute();You can read that as SQL. There is no abstraction layer hiding what hits the database. For a team that has SQL DBAs or backend engineers who think in tables and joins natively, this is liberating after the indirection of Prisma.
What You Give Up
Kysely will not protect a junior engineer from themselves. If you write a bad query, Kysely will run it. There is no include sugar to fall back on. There is no "smart" relation loading. Every join is explicit. Every column selection is explicit. For a senior team this is a feature; for a team with mixed experience it is a footgun factory.
You also need to maintain the database schema as TypeScript types yourself, or use a generator like kysely-codegen. I have used kysely-codegen against Postgres on the helpdesk app and it works, but it is one more piece of tooling to keep current.
My Honest Take On Kysely
Kysely is the most enjoyable to write of the four if you already think in SQL. It is also the easiest to build a custom abstraction on top of, because there is so little built-in opinion. Several teams I respect have built thin domain-specific layers on Kysely rather than adopt Prisma. If you have a strong backend team, this is a real option.
TypeORM: The Legacy Pick That Still Powers A Lot Of Money
TypeORM was the default Node ORM from roughly 2018 to 2022. Its decorator-based approach matched NestJS's style and the pairing felt natural for Java or C# refugees. A lot of NestJS payroll, billing, and admin systems still run on TypeORM in production right now. I worked on one of them last year — a Smart HR Payroll system for a client with about 400 employees on the platform.
What TypeORM Still Does Well
The Active Record and Data Mapper patterns are familiar to engineers from Rails or Django backgrounds. The decorator syntax for entity definitions is concise and explicit. The migration generation works for the common cases. If you onboard a backend engineer who has never seen TypeScript but knows ActiveRecord deeply, TypeORM is the gentlest landing.
What Hurts In 2026
Type safety. TypeORM's types lie to you in subtle ways. findOne will return Entity | null in some signatures and Entity | undefined in others, and the relation lazy-loading uses Promise<Entity> properties that look like sync getters. I have shipped at least three null-pointer bugs to staging because TypeORM told me a property was non-nullable when at runtime it was undefined because a relation had not been eager-loaded. Prisma and Drizzle both fail at compile time for the equivalent mistake.
Migration generation is also unreliable on schema changes that involve renames or type changes — I have learned to write TypeORM migrations by hand for anything more complex than adding a column.
The Postgres connection pool implementation has had ongoing issues with idle-timeout handling that hits you in serverless contexts. None of this is unfixable, but the maintainer attention to fix it has been inconsistent.
Should You Migrate Off TypeORM?
Only if you are going to rewrite the data access layer anyway. Migrating an existing app from TypeORM to Drizzle or Prisma takes weeks of work and introduces bugs in code that was previously stable. The pragmatic call I made on the payroll app was: keep TypeORM, write all new modules in Drizzle, let them coexist via a shared connection pool, and migrate one bounded context at a time when there is a real reason to touch it.
Head-To-Head Feature Matrix
| Feature | Prisma 7 | Drizzle | Kysely | TypeORM |
|---|---|---|---|---|
| Bundle size (gzipped) | ~600KB | ~7.4KB | ~25KB | ~180KB |
| Cold start on Vercel (measured) | ~180ms | ~95ms | ~110ms | ~340ms |
| Schema definition | Schema file | TypeScript | TypeScript types | Decorators |
| Migrations included | Yes (excellent) | Yes (good) | Plugin (decent) | Yes (flaky) |
| Multi-database | Yes | Yes (best) | Yes | Yes |
| Edge runtime support | Yes (since v7) | Yes (best) | Yes | Limited |
| Raw SQL ergonomics | Awkward | Good | Excellent | OK |
| Junior-friendly | Yes | OK | No | OK |
| NPM weekly downloads | ~3M | ~900K | ~250K | ~2.5M |
| Active maintenance | Strong | Strong | Steady | Inconsistent |
The cold-start numbers are from my own Vercel project running a simple findFirst by indexed primary key against a Neon Postgres database in the same region. Your numbers will vary based on your network path and the complexity of your queries, but the relative ordering held across every test I ran.
The Decisions I Have Actually Made For Real Projects
Talking in abstractions is easy. Here are the calls I have made, with reasoning, on shipped projects in the last 18 months:
Photography Studio Manager (Vue + Laravel backend, no TypeScript): not applicable, but worth noting that for our Laravel-heavy stacks I am using Eloquent and skipping the TypeScript ORM debate entirely. Right tool for the right runtime.
BizChat Revenue Assistant (Next.js + Postgres): Drizzle. Edge runtime mattered because we wanted fast streaming responses, and the schema was small enough that the lower abstraction was not painful.
Smart POS dashboard (Next.js + MySQL): Prisma 7. Mixed-experience team, schema had 24 tables with messy relations, the Prisma Studio inspector was worth its weight for debugging.
SmartExam AI Generator (Node backend + Postgres + pgvector): Kysely. The vector search queries combined with metadata filters were too painful to express in Prisma, and the team is small and senior.
Internal helpdesk reporting layer: Migrated from Prisma to Kysely. The reporting queries were already raw SQL through Prisma escape hatches, so removing the abstraction simplified the codebase.
Aggregator import pipelines (7 sites): Drizzle. Bundle size, edge deployability, and SQL transparency for the dedupe logic.
Smart HR Payroll (NestJS + Postgres): Stayed on TypeORM. Migration cost did not justify the benefit for a stable mature app.
Notice the pattern: there is no single right answer. The choice is shaped by the team, the runtime, and the query complexity, not by which tool is "best" in some abstract sense. Anyone telling you Drizzle is always better than Prisma, or vice versa, is selling you something.
What I Would Have Told 2022-Me
If I could send a message back to my 2022 self who was about to pick Prisma for a hotel management system that grew into a six-table mess of relations, I would say three things:
One: The ORM you pick at month one is not the ORM you will live with at year three. Migrations between ORMs are painful. Pick one that gives you an escape hatch to raw SQL without making you feel guilty about using it.
Two: Your bundle-size and cold-start performance will matter more than you think the moment you put the app on serverless or edge. Run a cold-start test on day one of the project, not in a panic the week before launch.
Three: Junior-friendliness is real and underrated. If you cannot ramp a new engineer to productive on your data layer in two days, you have either picked the wrong tool or written too much custom abstraction on top of the right one. Prisma optimizes for this. Kysely does not. Pick deliberately based on who will maintain the code.
FAQ
Is Drizzle production-ready? Yes. I have it running daily imports across seven sites and a Cloudflare Worker handling chat sessions. No surprises in production for the past 11 months.
Should I migrate from Prisma 5 or 6 to Prisma 7? Yes if you deploy to serverless or edge. The cold-start improvement is real and the migration is mostly painless. Read the breaking changes around $queryRaw tagged template literals before you start.
Is TypeORM dead? Not dead, but coasting. New projects should not start on TypeORM in 2026 unless there is a strong organizational reason (an internal NestJS template that everyone knows, for instance). Existing projects do not need to migrate urgently.
Can I use multiple ORMs in one app? Yes, and I do. Prisma plus Kysely is a common combo — Prisma for the CRUD layer, Kysely for reporting. Drizzle plus TypeORM coexisted on the payroll app for months without issues. Just keep the connection pooling sane.
What about MikroORM, Sequelize, Objection? MikroORM is a credible alternative I have not used heavily; from what I have read it sits between TypeORM and Prisma in style. Sequelize is older than TypeORM and I would not start a new TypeScript project on it. Objection is solid for Knex users but Knex is itself in maintenance mode.
What about Bun's native ORM bun:sqlite? Different category — that is a SQLite driver, not an ORM. Drizzle works on top of it nicely if you want SQLite ergonomics on Bun.
The Recommendation In One Sentence
If I had to pick a single ORM for a team starting a new TypeScript project today with no constraints, I would pick Drizzle for the bundle size and SQL transparency, then add Prisma later if the team complains about the lack of relation sugar — but I would not feel bad about anyone who picked Prisma 7 first either, because the gap closed a lot in 2026.
The worst pick is the one made without testing. Every time I have seen a team regret an ORM choice, it was because they read one comparison article and shipped without running a cold-start test on their actual deployment target. Spend the half-day. Run the test. Then commit.
