Confession: I spent two weeks last winter trying to convince myself that Prisma was still the right call for a side project I was rebuilding. The schema file looked clean, the type generation felt familiar, and I’d shipped enough Prisma apps that I could do it half-asleep. Then I deployed it to a Cloudflare Worker, watched the cold-start times, and quietly started porting the data layer to Drizzle that same night.<\/p>\n
Six months later I’ve used both in production on three different shapes of project: a Next.js app on Vercel, a small Hono API on Workers, and a long-running Node service on a Hetzner box. What I learned isn’t ‘Drizzle wins’. It’s that the choice has stopped being about features and started being about where your code runs, how comfortable you are reading SQL, and how much you care about your migrations behaving like, well, migrations.<\/p>\n
If you want the short answer: I default to Drizzle now, but Prisma is still the right tool for two specific cases. Read on if you want to know which two.<\/p>\n
Both ORMs ask you to declare your schema once and get types and queries from it. They just disagree on what ‘declare your schema’ means.<\/p>\n
In Prisma you write a In Drizzle the schema is just TypeScript. No DSL, no codegen step, no separate language to learn:<\/p>\n The Prisma file is shorter and reads almost like documentation. The Drizzle file is plain TS, so it composes with your existing tooling. You refactor across the codebase with the same Find References command you already use. You share types with your validation layer. You run codemods on it. After about a week of writing the TypeScript version I stopped missing the DSL. After two weeks I started liking that there was no codegen step to forget.<\/p>\n This is where I switched camps for good.<\/p>\n Prisma’s migration story is a wrapper around SQL. You change Drizzle uses The SQL file is the source of truth. If I’m not the only person who finds the SQL-first approach calming. Even the official Prisma migrate docs<\/a> recommend an Both give you autocompletion and end-to-end types. The shape of the output is where they part ways.<\/p>\n Prisma returns nested objects when you Drizzle gives you two flavors. There’s a SQL-like query builder that returns flat rows. You write the joins yourself, you read what comes back:<\/p>\n And there’s a relational query API that returns nested objects, much closer to Prisma’s feel:<\/p>\n The relational API was the thing that made Drizzle stop feeling like a step backward. I use it for most read paths because the inference is identical to Prisma’s mental model. I drop down to the SQL builder when I want a specific join order, a CTE, a window function, or anything else where I want to see the exact query the database will run. The escape hatch is the actual point, for me.<\/p>\n Prisma also has raw queries via This is what pushed me over the edge for the Workers deploy.<\/p>\n Prisma’s ORM ships a query engine, historically a Rust binary that gets bundled with your app or accessed via Data Proxy or Accelerate. The team has been steadily moving toward a TypeScript-native Prisma client<\/a> and it’s improved a lot, but on Cloudflare Workers and similar edge runtimes the binary path is still the dominant story for many setups. That means longer cold starts and a noticeable bundle hit.<\/p>\n Drizzle is just TypeScript. No binary, no separate process. On the same Hono API I measured a roughly 4x cold-start improvement and a bundle smaller by tens of kilobytes when I replaced Prisma plus Accelerate with Drizzle plus The flip side: Drizzle gives you nothing for connection pooling. You wire it up yourself with I wrote up the Postgres side of this in my notes on jsonb defaults<\/a>, because the ORM choice and the database choice keep colliding in ways I didn’t expect when I started.<\/p>\n A few specific areas where the two diverge in ways that matter to me.<\/p>\n JSON columns: Drizzle’s Row-level security: if you’re leaning on Postgres RLS the way I do for multi-tenant apps, you want fine control over the session settings. Both ORMs can do it, but with Drizzle I’m closer to the wire, which makes things like Studio and seeding: Prisma Studio is genuinely good. Drizzle Studio has caught up faster than I expected but still has rough edges around enum editing and large tables. For seed scripts I prefer Drizzle (it’s just TS calling Logging: Drizzle’s If you’re doing serious work, the kind I cover in my portfolio of full-stack projects<\/a>, these awkward bits add up faster than you’d guess.<\/p>\n Drizzle by default, especially for anything serverless or edge-deployed. The combination of plain TypeScript schemas, SQL-first migrations, and a tiny runtime is the closest thing to ‘ORM without regret’ I’ve used.<\/p>\n Prisma still wins for two cases I keep hitting:<\/p>\n A team that doesn’t read SQL comfortably. Prisma’s DSL plus the nested query API plus Studio is the gentlest on-ramp from ‘I know JavaScript’ to ‘I’m shipping a database-backed app’. I’ve onboarded juniors with Drizzle and they get there, but it takes longer.<\/p>\n<\/li>\n Apps that depend on Prisma-specific tooling. Accelerate for caching, Pulse for change streams, a Studio-driven workflow your PM uses every day. That ecosystem is real, and pulling out of it is more painful than the ORM itself.<\/p>\n<\/li>\n<\/ol>\n If you’re on the fence: pick a small read path in your current app, write it in both, then deploy both versions and watch the latency for a week. The right answer will show up faster than any blog post can tell you. Then come back and yell at me on my contact page<\/a> if I got it wrong.<\/p>\n","protected":false},"excerpt":{"rendered":" Drizzle vs Prisma in 2026: my honest take after six months in production on Next.js, Hono on Workers, and one boring Node service on a Hetzner box.<\/p>\n","protected":false},"author":2,"featured_media":301,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"rank_math_title":"","rank_math_description":"Drizzle vs Prisma in 2026: my honest take after six months in production on Next.js, Hono on Workers, and one boring Node service on a Hetzner box.","rank_math_focus_keyword":"drizzle vs prisma","rank_math_canonical_url":"","rank_math_robots":"","footnotes":""},"categories":[35],"tags":[180,61,182,177,181,63],"class_list":["post-302","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-web-development","tag-drizzle","tag-nextjs","tag-orm","tag-postgres","tag-prisma","tag-typescript"],"_links":{"self":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts\/302","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/comments?post=302"}],"version-history":[{"count":0,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts\/302\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/media\/301"}],"wp:attachment":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/media?parent=302"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/categories?post=302"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/tags?post=302"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}.prisma<\/code> file. It’s a small DSL the team built to look like a stripped-down GraphQL schema, and you run prisma generate<\/code> to turn it into a client. Here’s a tiny example:<\/p>\nmodel Post {\n id Int @id @default(autoincrement())\n slug String @unique\n title String\n body String\n published Boolean @default(false)\n createdAt DateTime @default(now())\n}\n<\/code><\/pre>\nimport { pgTable, serial, text, boolean, timestamp } from 'drizzle-orm\/pg-core';\n\nexport const posts = pgTable('posts', {\n id: serial('id').primaryKey(),\n slug: text('slug').notNull().unique(),\n title: text('title').notNull(),\n body: text('body').notNull(),\n published: boolean('published').notNull().default(false),\n createdAt: timestamp('created_at').notNull().defaultNow(),\n});\n<\/code><\/pre>\nMigrations: where the real friction lives<\/h2>\n
schema.prisma<\/code>, run prisma migrate dev<\/code>, and it writes a migration.sql<\/code> file plus a _prisma_migrations<\/code> tracking table. That works fine in development. In production it gets opinionated. The CLI wants to detect drift, wants to reset on conflict, and the failure modes when you’re recovering from a partial deploy are not fun to debug at 2am.<\/p>\ndrizzle-kit<\/code> to generate migrations from your TS schema, but the output is a plain SQL file you can read, edit, commit, and apply yourself. Generation looks like this:<\/p>\nnpx drizzle-kit generate\n# writes drizzle\/0001_add_published_flag.sql\nnpx drizzle-kit migrate\n# applies pending migrations using a tiny tracking table\n<\/code><\/pre>\ndrizzle-kit<\/code> generates something I don’t like, and it does occasionally for renames or partial unique indexes, I open the file and fix it before applying. There’s no clever drift detection trying to outsmart me. The Drizzle migrations docs<\/a> describe this as ‘manual migrations with codegen’, and that label is accurate.<\/p>\napply<\/code>-only workflow in production, which is essentially what Drizzle gives you by default. The gap closes once you wire your CI up carefully. But you have to wire it up carefully, and you don’t with Drizzle.<\/p>\nTypeScript inference: same idea, very different output<\/h2>\n
include<\/code> relations:<\/p>\nconst post = await prisma.post.findUnique({\n where: { slug: 'drizzle-vs-prisma' },\n include: { author: true, tags: true },\n});\n\/\/ post.author.name, post.tags[0].label\n<\/code><\/pre>\nconst rows = await db\n .select()\n .from(posts)\n .leftJoin(authors, eq(posts.authorId, authors.id))\n .where(eq(posts.slug, 'drizzle-vs-prisma'));\n<\/code><\/pre>\nconst post = await db.query.posts.findFirst({\n where: eq(posts.slug, 'drizzle-vs-prisma'),\n with: { author: true, tags: true },\n});\n<\/code><\/pre>\n$queryRaw<\/code>, but the ergonomics aren’t great and the types are looser. Drizzle’s tagged-template sql<\/code> helper is genuinely pleasant to read and types parameters correctly.<\/p>\nRuntime cost: cold starts, bundle size, edge runtimes<\/h2>\n
postgres.js<\/code>. Your mileage will vary, but the direction is consistent across every benchmark I’ve seen people post on the Drizzle GitHub discussions<\/a>.<\/p>\npostgres<\/code>, node-postgres<\/code>, neon-http<\/code>, @planetscale\/database<\/code>, whatever fits your runtime. Prisma at least pretends to manage connections for you. For a serverless app where I’m already using a pooler at the database level, that’s a wash. For a long-running Node service, Prisma’s behavior is slightly more turn-key, though the difference is small if you’ve ever configured a pool before.<\/p>\nWhat about JSON, RLS, and the awkward bits<\/h2>\n
jsonb<\/code> type takes a generic that types the contents, which is what I want most of the time. Prisma still returns Prisma.JsonValue<\/code>, and you cast or validate at the boundary. Neither is wrong; Drizzle’s is what I reach for.<\/p>\nset_config('app.user_id', ...)<\/code> simpler to thread through. Prisma’s session-variable story improved in recent releases, though it still feels like a workaround.<\/p>\ndb.insert<\/code>), but prisma db seed<\/code> is more standardized if your team needs a convention.<\/p>\nlogger<\/code> interface gives me the SQL with parameters out of the box, which is what I want during incidents. Prisma’s event.query<\/code> is decent but the format is noisier. This sounds like a small thing until you’re tailing logs on a Friday afternoon.<\/p>\nSo which one do I actually reach for now?<\/h2>\n
\n