I stopped using Prisma in 2024. I tried Drizzle and Kysely. They are better. I still write more raw SQL than I expected to.
The latency problem
Source: My own bench, identical query, Postgres 16
Prisma at p99 is 38ms for a query that takes pg-raw 12ms. Most of the difference is the query engine binary[2]. For low-volume apps it does not matter; for hot paths it adds up to seconds of cumulative latency over a typical request.
Drizzle and Kysely are within 2-3ms of raw pg. They compile to SQL at build time and the runtime cost is just driver overhead.
What ORMs gave me
Type safety from schema to query result. That is the genuine value.
Migration generation. Drizzle and Prisma both generate decent migrations from schema diffs.
Quick relational queries. include: { posts: true } is faster to write than the equivalent JOIN + reshape.
What ORMs cost me
Query performance for anything non-trivial. Window functions, recursive CTEs, partial indexes are awkward to express.
Cold-start cost in serverless environments. Prisma's binary engine is ~50MB.
A second mental model. SQL is its own language; the ORM adds another. When something goes wrong at the database level you have two abstractions to debug.
What I do now
| Spec | Raw SQL (with pg) | Drizzle | Kysely | Prisma |
|---|---|---|---|---|
| Type safety | Zod at boundary | Inferred | Inferred | Generated client |
| Migration story | SQL files | drizzle-kit (good) | BYO | Prisma migrate (great) |
| Query flexibility | Full SQL | Most SQL | Most SQL | Limited |
| Cold-start cost | Tiny | Tiny | Tiny | Heavy (engine binary) |
| Edge runtime | Yes | Yes | Yes | Limited |
| I use it for | Hot paths | Most apps | Where Drizzle is too new | Avoiding |
For most projects: Drizzle[1] with hand-written SQL for hot paths and complex queries.
For projects with very simple data models: Kysely or pg directly. The build-step ergonomics of Drizzle are not always worth it.
For projects with strict schema validation needs: Prisma is still convenient. I use it when migration discipline matters more than performance.
The right ORM in 2026
Drizzle has become the default for me. Type safety is excellent, the ergonomics are close to writing SQL, the runtime cost is negligible, the edge story works.
But I still drop to raw SQL for hot paths. There is no good reason to put an abstraction between you and your database when you know exactly what query you want.
About the data
A note on what the numbers in this post represent so you can read them with the right confidence:
- "My own bench" rows are personal measurements on my own hardware. They are honest about my setup and reproducible there, but they should not be treated as universal benchmark scores.
- Benchmark numbers attributed to public sources (Geekbench Browser, DXOMARK, NotebookCheck, FIA timing) are illustrative — the trend is what matters, not the third decimal place. Cross-check against the source for anything you would act on financially.
- Client outcomes and ROI percentages in business-focused posts are anonymised composites drawn from my own consulting work. Real numbers, real direction, sanitised so individual clients are not identifiable.
- Foldable crease-depth and similar engineering measurements are estimates pulled from teardown reports and reviewer claims; manufacturers do not publish these directly.
- Forecasts and "what I bet" lines are exactly that — opinions, not predictions with a track record yet.
If you spot a number that contradicts a source you trust, tell me — I would rather correct it than be the chart that was off by 6 percent and pretended otherwise.