Drizzle vs Prisma: warum wir beide in Produktion nutzen

Drizzle vs Prisma ist für uns kein Unentschieden, aber auch kein Duell mit Sieger. Wir betreiben beide in Produktion: Prisma auf Postgres in älteren Kunden-Apps und Drizzle auf Cloudflare D1 in jeder neuen App, seit wir neue Arbeit auf Workers bauen. Die kurze Antwort: Nehmen Sie Drizzle, wenn Sie auf eine Serverless- oder Edge-Umgebung deployen und Schema und Migrationen als reines TypeScript und SQL wollen. Behalten Sie Prisma dort, wo es schon funktioniert.

Die meisten Vergleiche schreibt einer der beiden Anbieter oder jemand, der eine Demo zweimal gebaut hat. Dieser stammt aus Repositories, die wir pflegen, mit der Konfiguration, wie sie ist.

Drizzle vs Prisma: was ist der eigentliche Unterschied?

Beide geben Ihnen einen typisierten Datenbank-Client in TypeScript. Der Unterschied liegt darin, wo das Schema lebt und wie weit das ORM von SQL entfernt ist.

Die Drizzle-Dokumentation beschreibt es als „dialect-specific, slim, performant and serverless-ready by design“ (Drizzle overview, geprüft am 24.10.2026). Prisma ist das Werkzeug eine Ebene höher: Sie beschreiben Modelle, und Prisma entscheidet das SQL.

Warum laufen neue Apps auf Drizzle?

Unsere neuen Apps laufen auf Cloudflare Workers mit D1, also SQLite. Unser Starter-Template und unsere internen Werkzeuge teilen dasselbe Setup. Die gesamte Drizzle-Konfiguration ist diese:

// packages/db/drizzle.config.ts
import { defineConfig } from 'drizzle-kit'

export default defineConfig({
  schema: './src/schema',
  out: './src/migrations',
  dialect: 'sqlite',
  driver: 'd1-http',
})

Das Schema ist eine TypeScript-Datei. Gekürzt aus unserem Starter:

// packages/db/src/schema/records.ts
import { sql } from 'drizzle-orm'
import { integer, sqliteTable, text } from 'drizzle-orm/sqlite-core'
import { user } from './auth'

const record = sqliteTable('record', {
  id: text('id').primaryKey().$defaultFn(() => crypto.randomUUID()),
  name: text('name').notNull(),
  status: text('status', { enum: ['active', 'inactive', 'pending'] }).default('active').notNull(),
  createdById: text('created_by_id').references(() => user.id, { onDelete: 'set null' }),
  createdAt: integer('created_at', { mode: 'timestamp_ms' })
    .default(sql`(cast(unixepoch('subsecond') * 1000 as integer))`)
    .notNull(),
})

Der Client ist eine Zeile über dem D1-Binding, und eine Abfrage liest sich wie SQL:

import { drizzle } from 'drizzle-orm/d1'
import * as schema from './schema'

const createDb = () => drizzle(env.DB, { schema })

const [total] = await ctx.db.select({ count: count() }).from(record)

Drei Gründe haben uns für neue Arbeit wechseln lassen:

• Die Laufzeitumgebung. Ziel waren D1 und Workers. Drizzle verbindet sich mit import { drizzle } from 'drizzle-orm/d1' (Drizzle und D1).
• Der Agent liest das Schema direkt. KI schreibt heute unseren gesamten Code, und ein Senior steht für die Produktion gerade. Ein Schema in TypeScript ist einfach Code: Der Agent ändert es, der Type-Checker findet eine falsche Spalte sofort, und es gibt keinen generierten Client, dessen Neugenerierung man vergessen kann.
• Migrationen sind SQL im PR. Wer reviewt, sieht das genaue ALTER TABLE, nicht den Diff einer Modelldatei.

Die Anmeldung nutzt dieselbe Datenbank. Better Auth wird mit drizzleAdapter(db, { provider: 'sqlite' }) angebunden, Nutzer und Sessions sind also gewöhnliche Tabellen neben denen der App.

Wie kommt eine Schemaänderung in die Produktion?

Eine Änderung läuft in jeder neuen App gleich. Niemand führt SQL von Hand gegen die Produktion aus.

Die Deployment-Seite steht in unserem Infrastruktur-Code, in TypeScript mit Alchemy:

// packages/infra/alchemy.run.ts (gekürzt)
const db = await D1Database('database', {
  migrationsDir: '../../packages/db/src/migrations',
})

const web = await TanStackStart('web', {
  cwd: '../../apps/web',
  bindings: { DB: db },
})

Ein Ordner mit SQL-Dateien ist die ganze Geschichte der Datenbank. Auch deshalb ist eine Übergabe für den nächsten Entwickler lesbar.

Wo gewinnt Prisma noch, und warum behalten wir es?

Mehrere ältere Kunden-Apps laufen mit Prisma auf Postgres, über mehrere Prisma-Hauptversionen hinweg. Eine davon ist das System einer Spedition, das wir gebaut haben und betreiben. Die meisten nutzen das klassische Setup: prisma-client-js, NextAuth mit dem Prisma-Adapter und prisma migrate deploy im Build-Skript, sodass jedes Deployment zuerst die Datenbank aktualisiert und erst dann next build startet.

Dieses Setup funktioniert. Die Modellsprache von Prisma liest sich gut, auch für jemanden, der nicht täglich SQL schreibt, und der Migrationsablauf ist ausgereift. Aus einer App, die ihren Nutzern gut dient, gibt es keinen Grund, sie zu entfernen.

Ein ORM-Wechsel trifft jede Abfrage, jeden Test und jede Migration auf einmal, und der Nutzer sieht nichts Neues. Dieses Risiko lohnt sich nur, wenn etwas anderes es erzwingt, etwa ein Umzug auf Workers. Wenn wir eine ältere App übernehmen, ist das ORM selten das Erste, was sich zu reparieren lohnt. Wie wir auswählen, was zuerst kommt, steht in Technische Schulden: wie messen und was zuerst beheben?.

Noch eine ehrliche Anmerkung: Der Online-Marktplatz eines Kunden läuft auf MongoDB mit Mongoose, dort ist also keines der beiden ORMs im Einsatz.

Was hat Prisma 7 geändert?

Viele Vergleiche „Drizzle vs Prisma“ streiten noch über das Rust-Engine-Binary. Dieses Argument ist schwächer geworden. Prisma ORM 7 erschien am 19.11.2025 mit „Rust-free Prisma Client as the default“ (Prisma Changelog, geprüft am 24.10.2026). Der Upgrade-Leitfaden sagt:

Derselbe Leitfaden sagt, dass ein Driver Adapter jetzt für jede Datenbank Pflicht ist. Prisma 7 läuft also auch auf Workers und auf D1 über @prisma/adapter-d1. Die D1-Seite von Prisma ergänzt eine Warnung, die für jedes ORM gilt: D1 unterstützt keine Transaktionen, also „implicit & explicit transactions will be ignored and run as individual queries“ (Prisma und Cloudflare D1, geprüft am 24.10.2026).

Ehrlich gesagt: Wir haben Drizzle nicht gegen Prisma 7 gemessen und Prisma 7 noch nicht auf D1 betrieben. Die meisten unserer Prisma-Apps laufen noch auf prisma-client-js, nur die neueste nutzt schon den neuen Generator prisma-client. Wenn Sie heute vergleichen, vergleichen Sie mit Prisma 7, nicht mit der Version aus alten Blogposts.

Drizzle oder Prisma für Ihre nächste App?

Gehen Sie die Punkte durch. Je mehr davon bei Ihnen zutreffen, desto besser passt Drizzle:

Egal, was Sie wählen: Halten Sie die Migrationen im Repository und spielen Sie sie aus dem Deployment ein, nie von Hand. Steht ohnehin ein Neuschreiben im Raum, lesen Sie zuerst Refactoring oder neu schreiben? So entscheiden Sie.

Möchten Sie eine Web-App mit einer Datenschicht, die auch der nächste Entwickler versteht?

Wir bauen Web-Apps auf diesem Stack, für neue Arbeit Drizzle auf D1, und übernehmen Prisma-Apps, ohne neu zu schreiben, was funktioniert: Webanwendungen nach Maß. KI schreibt heute unseren gesamten Code, und ein Senior steht für das Ergebnis gerade. Seit 2023 haben wir 15+ Produktionsprojekte geliefert.

Wir melden uns innerhalb von zwei Arbeitstagen und wählen gemeinsam, was wir zuerst lösen.

Wenn Sie lieber zuerst sprechen möchten, buchen Sie ein 15-Minuten-Meeting mit Filip.

Über welches ORM streitet Ihr Team gerade?

Häufige Fragen

Ist Drizzle besser als Prisma?

Keines ist generell besser. Drizzle passt zu Serverless- und Edge-Umgebungen wie Cloudflare Workers mit D1, hält das Schema in reinem TypeScript und bleibt nah an SQL. Prisma passt zu Teams, die einen höheren Client, einen eigenen Migrationsablauf und Werkzeuge wie Prisma Studio wollen, typischerweise auf Postgres.

Braucht Prisma noch ein Rust-Engine-Binary?

Seit Prisma ORM 7, veröffentlicht am 19.11.2025, nicht mehr. Der neue Generator prisma-client nutzt einen Client ohne Rust und braucht für jede Datenbank einen Driver Adapter. Apps auf prisma-client-js mit Prisma 5 oder 6 nutzen standardmäßig die Rust-Engine.

Läuft Prisma mit Cloudflare D1?

Ja, über den Driver Adapter @prisma/adapter-d1. Die Prisma-Dokumentation warnt, dass D1 keine Transaktionen unterstützt, implizite und explizite Transaktionen laufen also als einzelne Abfragen. Diese D1-Grenze gilt für jedes ORM.

Sollten wir eine bestehende Prisma-App auf Drizzle umstellen?

Meistens nicht. Die Datenschicht einer funktionierenden App neu zu schreiben, ist ein echtes Risiko und bringt den Nutzern nichts Neues. Wir wechseln zu Drizzle bei einer neuen App oder wenn sich die Laufzeitumgebung ändert, etwa zu Cloudflare Workers.

Wie funktionieren Migrationen in Drizzle?

Sie ändern das Schema in TypeScript, drizzle-kit generate schreibt eine reine SQL-Migrationsdatei, und diese wird beim Deployment eingespielt. Bei uns geht die SQL-Datei im selben PR wie die Schemaänderung durch das Code-Review.