I switched a Next.js app from Prisma to Drizzle last spring, and about three weeks in I hit a bug that made me want to switch it back.<\/p>\n
Then I fixed the bug in about six lines, remembered why I moved off Prisma, and haven’t looked back since.<\/p>\n
I get asked which one to pick roughly once a week now. Usually by someone who’s been reading React threads on Twitter and is convinced they need to migrate their whole stack tomorrow. The honest answer is that it depends on how much you like magic, how much you care about bundle size, and whether you want to write SQL or pretend SQL doesn’t exist.<\/p>\n
Here’s how I actually pick between them in 2026.<\/p>\n
Quick calibration so we’re arguing about the same thing. Prisma is the ORM with the schema DSL ( The Drizzle docs<\/a> call themselves a “headless TypeScript ORM.” I keep calling Drizzle a “query builder with a personality,” which is closer to how it feels day to day. Prisma calls itself an “ORM for Node.js and TypeScript” and the Prisma docs<\/a> will not stop telling you about the Prisma Client, the Migrate CLI, and the Studio GUI.<\/p>\n That framing already tells you the vibe. Drizzle wants to get out of your way, Prisma wants to be a whole ecosystem.<\/p>\n Prisma’s schema file looks like this:<\/p>\n It’s neat. It’s readable. It’s also a completely separate language that VS Code has to have a plugin for, and if you want to add a column with a specific Postgres feature (say, a generated column or a Drizzle just uses TypeScript:<\/p>\n More verbose. Uglier at first glance. But when I want to add a check constraint or an obscure Postgres type, I can. There’s no “we don’t support that yet” issue open on GitHub with 400 upvotes. I found this out the hard way trying to get a If you value one file that reads like a textbook definition of your data model, Prisma wins. If you value being able to reach for any SQL feature without waiting on the ORM team, Drizzle wins.<\/p>\n This is the actual battle line. Consider “get the last 10 posts for a user, with their comment counts, ordered by score.”<\/p>\n Prisma:<\/p>\n Very readable. Also lies about what’s happening under the hood. Prisma issues multiple queries by default and stitches results together in Node, and getting it to do a single SQL query with the count as a joined aggregate is either awkward or annoyingly deep in the docs, depending on the day.<\/p>\n Drizzle:<\/p>\n Longer. But that’s one SQL query. I can copy it out of the logs, paste it into If your queries are simple CRUD and you don’t care about the SQL, Prisma is friendlier. The moment you start writing anything a DBA would recognise, Drizzle’s approach starts saving you.<\/p>\n This is where I actually got burned.<\/p>\n I had a Prisma-powered Next.js app deployed on Vercel with a bunch of edge runtime routes. Prisma’s query engine at the time (Rust WASM) shipped a fat blob to the edge and my cold starts went from “fine” to “why is the first request taking 1.2 seconds.” Prisma has been rewriting the engine in pure TypeScript, and it’s better now. The Prisma blog on the TypeScript client rewrite<\/a> explains what changed. But if you’re chasing edge cold-start numbers, you still care about size.<\/p>\n Drizzle is a small pure-TypeScript library with no code generation and no engine. My deployed function bundle dropped by about 40% after the migration, and edge cold starts on the same routes fell into the 200ms range. Individual numbers vary. But the direction is consistent, and every serverless engineer I’ve compared notes with tells me the same story.<\/p>\n If your app is a stateful long-running Node.js server, this section doesn’t matter to you. If you deploy to Vercel, Cloudflare Workers, Netlify, or any Function-as-a-Service setup, it does.<\/p>\n Prisma has a bigger toolbox out of the box. Drizzle has Trade-off in one line: Prisma gives you conventions, Drizzle gives you control. If your team is more than four people or your app has been running for more than a year, control tends to matter more than conventions.<\/p>\n For a new serverless project with a small team and mostly CRUD, I still reach for Prisma. Get to shipping. Come back to this decision in a year.<\/p>\n For a new app targeting the edge, or where bundle size matters, I go with Drizzle. Save yourself the migration later.<\/p>\n For a big existing app with real query complexity or a serious DBA in the room, I go with Drizzle too. You’ll write more code, but you’ll be able to reason about it.<\/p>\n If you’re on Rust or Go, neither of these, obviously. I wrote about my Rust backend setup with axum and sqlx<\/a> if that’s what you’re actually building.<\/p>\nschema.prisma<\/code>), a code generator, and a query engine that used to be a Rust binary and now runs in TypeScript. Drizzle is a thinner layer: you define your schema in plain TypeScript files, and you write queries that look a lot like SQL. Both target Postgres, MySQL, SQLite, and the usual serverless-first Postgres providers.<\/p>\nThe schema experience: DSL vs TypeScript<\/h2>\n
model User {\n id String @id @default(cuid())\n email String @unique\n createdAt DateTime @default(now())\n posts Post[]\n}\n<\/code><\/pre>\ncitext<\/code>) you’ll spend twenty minutes searching the docs for the exact incantation.<\/p>\nimport { pgTable, serial, text, timestamp, uniqueIndex } from "drizzle-orm\/pg-core";\n\nexport const users = pgTable("users", {\n id: serial("id").primaryKey(),\n email: text("email").notNull(),\n createdAt: timestamp("created_at").defaultNow().notNull(),\n}, (t) => ({\n emailUnique: uniqueIndex("users_email_unique").on(t.email),\n}));\n<\/code><\/pre>\ntsvector<\/code> column onto a Prisma model in 2024. In Drizzle, it’s a customType<\/code> in a file I already own.<\/p>\nQuery ergonomics: are you writing SQL or hiding from it?<\/h2>\n
const posts = await prisma.post.findMany({\n where: { authorId },\n orderBy: { score: "desc" },\n take: 10,\n include: {\n _count: { select: { comments: true } },\n },\n});\n<\/code><\/pre>\nimport { eq, desc, sql } from "drizzle-orm";\n\nconst posts = await db\n .select({\n id: postsTable.id,\n title: postsTable.title,\n score: postsTable.score,\n commentCount: sql`count(${commentsTable.id})`.as("comment_count"),\n })\n .from(postsTable)\n .leftJoin(commentsTable, eq(commentsTable.postId, postsTable.id))\n .where(eq(postsTable.authorId, authorId))\n .groupBy(postsTable.id)\n .orderBy(desc(postsTable.score))\n .limit(10);\n<\/code><\/pre>\npsql<\/code>, and understand exactly what’s going to hit the database. When something is slow in production, that matters more than I want to admit.<\/p>\nBundle size and the serverless edge case<\/h2>\n
Migrations, seeding, and the ecosystem stuff<\/h2>\n
prisma migrate dev<\/code>, prisma studio<\/code>, prisma db seed<\/code>, all wired together, all with a docs page you can hand to a junior developer. It’s the batteries-included pitch, and for a small team spinning up their first backend it’s genuinely nice. I still recommend Prisma to friends who are new to TypeScript backend work for exactly this reason.<\/p>\ndrizzle-kit<\/code> for migrations and drizzle-studio<\/code> for a GUI, and both work, but you’ll write more glue yourself. Seeding is “write a TypeScript file that runs inserts.” Migrations are generated from a diff against your schema, but you’re the one running them in your deploy pipeline. This isn’t hard. It’s just work you’d get for free with Prisma.<\/p>\nWhere I’m actually landing in 2026<\/h2>\n