TypeORM vs Drizzle vs Prisma vs Kysely
TypeORM vs Drizzle vs Prisma vs Kysely
TypeORM vs Drizzle vs Prisma vs Kysely in 2026 comes down to two questions: where does your code run, and what does your team already know? Prisma still has the best DX and the deepest hiring pool. Drizzle wins for Next.js on the edge and TypeScript-native types. Kysely is the pure query builder for SQL-first teams. TypeORM is legacy but still correct for Nest enterprise codebases.
The four ORMs are not interchangeable. They sit in different shapes of the same problem space. Picking the wrong one for your stack costs you weeks of rewrites later, and picking the right one for the wrong team costs you the same weeks in onboarding. This post is the honest 4-way matrix, with real numbers and a decision tree by stack and familiarity.
Prisma: best DX, biggest pool, the safe default
Prisma is the reigning TypeScript ORM by mindshare. Schema-first, with a .prisma DSL that compiles to a typed client. The DX is genuinely the best in the category: autocomplete is sharp, error messages are readable, and Prisma Studio gives you a free admin UI for any database. If you have ever onboarded a junior engineer in two days, you know how much that matters.
The 2025-2026 story for Prisma is the Prisma 7 rewrite. The old Rust query engine shipped a ~14MB native binary that broke serverless cold starts. The new TypeScript and WebAssembly engine drops that to ~1.6MB (about 600KB gzipped), an 85 to 90% reduction. Prisma's own benchmarks show cold-start improvement of up to 9x on Lambda, and read-heavy queries running up to 3.4x faster on large result sets.
Where Prisma still loses: relational query construction is verbose for nested filters, the prisma generate step adds friction during active development, and on raw throughput, the WASM engine is still ~30% slower than a tuned query builder. If you are pushing 50K req/s on a single Postgres node, Prisma is the wrong tool. For everyone else, it is the safe default.
Drizzle: TS-native, edge-native, SQL-shaped
Drizzle is the ORM that took the "schema as TypeScript code" idea to its logical end. Your tables are plain pgTable calls in a .ts file. Types flow from those definitions directly. There is no codegen step and no runtime schema. The query API reads like SQL: db.select().from(users).where(eq(users.id, 1)).
The numbers tell the rise. Drizzle is at ~32,000 GitHub stars and roughly 900,000 weekly npm downloads. Weekly downloads crossed Prisma in 2025, which is the kind of crossing you only do once. Bundle size is the real moat: ~5 to 7KB gzipped versus Prisma's ~600KB WASM blob. On a Vercel Edge function, that difference is felt at every cold start. For Cloudflare Workers, where the bundle limit is 1MB on the free tier, Drizzle is effectively the only ORM that fits comfortably.
Drizzle's weak spots are real but shrinking: migration tooling (drizzle-kit) is younger than Prisma's, the relational-query API has fewer affordances than prisma.user.findMany({ include: ... }), and there is no equivalent to Prisma Studio in the box. For most new TS-Postgres apps shipping in 2026, those trades are worth it. For an honest take on the binary choice, see our Drizzle vs Prisma deep-dive.
Kysely: the type-only escape hatch
Kysely is not an ORM. It is a TypeScript-first query builder. You define a single Database interface (a TS type, not a runtime schema) and Kysely gives you db.selectFrom('users').where('id', '=', 1).execute() with full type inference on every column and join. The bundle is ~8KB gzipped. Migrations are bring-your-own (most teams use kysely-migrate or hand-rolled SQL files).
Kysely is the right pick when your team thinks in SQL first. There is no schema language to learn, no decorators to maintain, and the API stays out of your way for hairy queries (recursive CTEs, window functions, lateral joins) that ORMs always make awkward. In published Northwind-style benchmarks, Kysely runs about 92K rps on the same workload where raw SQL hits 100K, an 8% overhead. That is the lowest in the field by a clear margin.
The flip side: no Kysely Studio, no schema-as-source-of-truth (your TS interface and your real database can drift), and a smaller hiring pool. Kysely engineers tend to be senior because Kysely is the kind of tool senior engineers pick on purpose. If you need to onboard three juniors next quarter, this is not the move.
TypeORM: legacy, decorators, the Nest default
TypeORM shipped in 2016. It predates the current TS ORM wave and it shows. Entities are classes decorated with @Entity, @Column, @OneToMany. You pick between Active Record (User.findOne) and Data Mapper (repo.findOne) per project. Migrations are built in but require manual generation. There is no edge runtime story; TypeORM depends on Node-specific drivers and will not run on Workers or Vercel Edge.
So why is TypeORM still on this list? Two reasons. First, NestJS tutorials and most Nest enterprise codebases default to TypeORM. If you have a 100K-line Nest API in production, ripping out TypeORM is a six-month migration with no business upside. Second, the decorator pattern is genuinely familiar to engineers coming from Spring, .NET, or older Java/Hibernate stacks. For an enterprise Nest team with that background, TypeORM is the path of least resistance.
Where TypeORM loses: type inference on relations is loose compared to Prisma or Drizzle, the maintenance pace has slowed, and bundle size sits around ~80KB even before drivers. For a green-field 2026 project, there is almost no reason to pick it over the other three.
Head-to-head: cold start, throughput, bundle, edge
Here is the honest matrix.
| Factor | Prisma | Drizzle | Kysely | TypeORM |
|---|---|---|---|---|
| Bundle (gzip) | ~600KB (v7 WASM) | ~5 to 7KB | ~8KB | ~80KB |
| Cold start (Lambda, first query) | 80 to 150ms | 50 to 100ms | 40 to 90ms | 120 to 200ms |
| Throughput vs raw SQL (Northwind) | ~71K rps (29% overhead) | ~88K rps (12% overhead) | ~92K rps (8% overhead) | ~65K rps (35% overhead) |
| Edge runtime | Yes (HTTP adapter) | Native | Native (HTTP driver) | No |
| Schema source | DSL (.prisma) | TS code | TS interface only | Decorators on classes |
| Migrations | Built-in, mature | drizzle-kit, growing | BYO | Built-in, manual |
| Admin UI | Prisma Studio | None (BYO) | None (BYO) | None (BYO) |
| First release | 2019 | 2022 | 2021 | 2016 |
| Hiring pool | Largest | Growing fastest | Small, senior | Plateauing |
Two things worth flagging from the table. Bundle size and cold start are not the same metric, but they correlate. Drizzle and Kysely cold-start fastest because there is barely anything to load. And the Prisma 7 WASM rewrite is real: Prisma cold starts now sit in the same order of magnitude as Drizzle, where Prisma 6 with the Rust binary used to be 5 to 10x slower.
Decision matrix: stack times team familiarity
Pick the column for your stack, then sanity-check against your team.
| Stack | First choice | Why | Backup |
|---|---|---|---|
| Next.js on Vercel (mostly edge) | Drizzle | Bundle + native edge support | Prisma with Accelerate |
| Next.js on Node (RSC + Route Handlers) | Prisma | DX still wins; cold start is fine on Node | Drizzle |
| Standalone Node API (Express, Fastify, Hono) | Drizzle or Prisma | Pick by team familiarity | Kysely if SQL-heavy |
| NestJS enterprise (>50K LOC) | TypeORM | Don't fight the framework default | Prisma if green-field Nest |
| Cloudflare Workers / Deno Deploy | Drizzle | Only ORM that fits the budget reliably | Kysely with HTTP driver |
| High-throughput SQL-first (analytics, fintech) | Kysely | Closest to raw SQL with types | Drizzle |
| Team already deep in Prisma | Prisma | Don't churn the team for benchmarks | Stay |
The "team familiarity" axis is the one most blog posts skip. A team of three Prisma-fluent engineers will ship faster on Prisma than on a "better" ORM they have to learn. The cost of switching ORMs is not the migration script. It is the six weeks of slower velocity while everyone reads the docs. For most teams, the right answer is the ORM your senior engineer already knows, unless your stack literally cannot run it (edge, Workers).
If you want a structured walk-through of the trade-offs against your actual roadmap, the decide tool on Cadence gives a Build/Buy/Book recommendation in 60 seconds.
What this means for hiring
The ORM you pick shapes who you can hire next quarter. From Cadence's 12,800-engineer pool (every engineer on the platform is AI-native by default, vetted on Cursor and Claude Code fluency before they unlock bookings), here is roughly how the four ORMs map to engineer availability in May 2026:
- Prisma engineers: Largest pool by a wide margin. About 38% of TS-Postgres backend engineers list it as primary. Median time to first commit on a Prisma codebase: 27 hours.
- Drizzle engineers: Fastest-growing slice, currently around 24% of the same pool, up from 9% a year ago. Most are also Prisma-fluent.
- Kysely engineers: Roughly 6%, almost entirely senior or lead tier ($1,500 to $2,000/week). Rare but high-signal.
- TypeORM engineers: Plateauing at ~22%, concentrated in Nest backgrounds. Skews toward mid and senior.
If you are hiring for a Drizzle stack and the local market is mostly Prisma engineers, the realistic path is to book a senior who has shipped both. The 48-hour free trial on Cadence is built for exactly this: try the engineer two days at no cost, see whether the ORM crossover is real, replace any week without notice. Cadence's trial-to-active conversion runs 67%, which means most trials end with the team keeping the engineer; the trial is a real filter, not a formality. Compare that to the typical recruiter loop in our staff aug vs managed services breakdown.
Whichever ORM wins your decision, the hiring loop should not. If you want a sanity check on which path makes sense for your specific stack and timeline, see how Cadence compares to the recruiter and freelance routes.
When to choose each, in one line
- Choose Prisma if your team is already on it, your DX matters more than your last 30% of throughput, and you are not running on the edge.
- Choose Drizzle if you are shipping on Vercel Edge or Cloudflare Workers, your team writes TS-first, and bundle size is in your budget.
- Choose Kysely if your team thinks in SQL, you are doing analytics or fintech-style query work, and you want the lowest abstraction tax.
- Choose TypeORM if you have a NestJS enterprise codebase and the cost of switching is bigger than the cost of staying.
If you are picking an ORM right now and want a vetted engineer who has shipped on more than one of these, Cadence shortlists 4 candidates in 2 minutes with a 48-hour free trial. Weekly billing, no notice period, daily ratings drive auto-replacement. Pricing runs Junior $500/week, Mid $1,000/week, Senior $1,500/week, Lead $2,000/week.
FAQ
Which TypeScript ORM is fastest?
Kysely and Drizzle are within ~8 to 12% of raw SQL throughput in Northwind-style benchmarks. Prisma 7 closed the gap dramatically with its WASM rewrite but still trails by ~30% on read-heavy loads. TypeORM is the slowest of the four. For most apps under 10K req/s per node, the difference is not measurable in production.
Can I migrate from Prisma to Drizzle?
Yes. Drizzle ships a drizzle-kit introspect command that generates a TS schema from an existing Postgres database. Most teams migrate incrementally, one route or one service at a time, running both ORMs side by side until the cutover is clean.
Is TypeORM still maintained?
Yes, but the pace is slow compared to the other three. It remains the default ORM in NestJS tutorials, which keeps it alive in enterprise Nest codebases. For new green-field projects in 2026, most teams pick Prisma or Drizzle instead.
Does Kysely have an admin UI like Prisma Studio?
No. Kysely is a query builder, not a full ORM. You bring your own admin UI (Outerbase, pgAdmin, TablePlus, Beekeeper) or skip the admin UI entirely. Many Kysely teams pair it with Drizzle's schema layer just to get migration tooling and an inspector.
Which ORM works best on Vercel Edge or Cloudflare Workers?
Drizzle is the cleanest fit, with native HTTP drivers for Neon, PlanetScale, and Turso. Kysely also runs on the edge with HTTP dialects. Prisma works via the Accelerate adapter (with a small per-query latency tax). TypeORM does not run at the edge at all and is not on the roadmap.
How do these ORMs compare to picking a backend framework like Express, Fastify, or Hono?
ORMs and frameworks are independent decisions. You can run Drizzle inside Express or Prisma inside Hono. If you are also evaluating the framework layer, see our Express vs Fastify vs Hono breakdown for how the runtime choice interacts with edge-vs-Node deployment.