Letzten Frühling war ich drei Wochen in ein SaaS-Nebenprojekt involviert, hatte Supabase angebunden, und starrte auf eine Wegkreuzung: Drizzle oder Prisma. Ich hatte Prisma wahrscheinlich auf vierzig-plus Client-Builds bei Seahawk verwendet. Bekanntes Terrain. Aber ein Junior Dev im Projekt drängte ständig auf Drizzle, und ehrlich gesagt war ich anfangs etwas abweisend. „Es ist neuerer. Weniger erprobt. Lass uns einfach Prisma nehmen."
Ich hätte es nicht so schnell abbügeln sollen.
Wir versuchten am Ende beide auf verschiedenen Teilen der gleichen Codebasis (chaotisch, ja, aber lehrreich). Was ich lernte, änderte, wie ich über ORM-Wahl überhaupt denke. Wenn du auf Supabase baust und wirklich unsicher bist, welches du wählen sollst, ist dies der Post, den ich mir gewünscht hätte.
---
Was du wirklich wählst
Diese zwei Tools lösen das gleiche oberflächliche Problem: du willst nicht jedes Mal rohes SQL schreiben, wenn du die Datenbank anfasst. Aber sie kommen aus sehr unterschiedlichen Philosophien.
Prisma behandelt dein Schema als die einzige Wahrheitsquelle. Du definierst eine schema.prisma Datei, führst prisma generate aus, und bekommst einen vollständig typisierten Client. Es abstrahiert SQL fast komplett. Du denkst selten in Tabellen und Joins; du denkst in Models und Relations.
Drizzle sitzt viel näher an SQL. Dein Schema wird in TypeScript definiert, deine Queries sehen wie SQL aus, und es gibt keinen separaten CLI-generierten Client in der Mitte. Es wird beschrieben als eine „TypeScript ORM, die sich wie SQL anfühlt" und das ist wirklich korrekt.
Weder ist objektiv besser. Punkt. Die Wahl hängt von deinem Team, deinen Query-Mustern und davon ab, wie sehr du Supabase's eigener Tooling traust, um die schwere Arbeit zu tragen.
---
Der Supabase-Kontext ändert alles
Hier ist das, was die meisten Vergleichs-Posts übersehen: Supabase ist nicht nur eine leere Postgres-Datenbank. Es kommt mit Row Level Security, Echtzeit-Abos, auto-generierten REST und GraphQL APIs, und seinem eigenen JavaScript-Client. Du machst oft schon viel durch supabase-js, bevor du überhaupt einen ORM anfasst.
Die eigentliche Frage ist also nicht nur „welches ORM ist besser?" Sondern: „Wie viel meiner Abfragelogik sollte über ein ORM laufen versus direkt über den Supabase-Client?"
Ich habe Teams gesehen, die Prisma gewählt haben, supabase-js fast vollständig ignoriert haben und sich dann gewundert haben, warum ihre RLS-Richtlinien nicht greifen. Das liegt daran, dass Prisma sich direkt über die Verbindungszeichenkette mit Postgres verbindet. Es umgeht die Supabase PostgREST-Schicht. Deine RLS-Regeln? Sie werden nur erzwungen, wenn du Prisma anweist, SET LOCAL role = authenticated auf Sitzungsebene zu setzen. Das ist nicht schwierig einzurichten, aber du musst wissen, dass es überhaupt eine Option ist.
Drizzle hat das gleiche Problem. Direkte Postgres-Verbindung, gleiches Umgehungsverhalten. Aber weil sich Drizzle näher an SQL anfühlt, sind Entwickler sich in der Regel bewusster, dass sie direkt mit Postgres sprechen, nicht über die Supabase-Abstraktion.
---
Bundle-Größe und Cold Starts: Das Serverless-Argument
Falls du auf Vercel Edge Functions, Cloudflare Workers oder sogar auf Standard-Vercel-Serverless-Functions deployst, ist die Bundle-Größe ein echtes Problem.
Der generierte Prisma-Client ist... groß. Die Query Engine allein ist eine Binärdatei, die mit deinem Deployment gebündelt wird. Eine Zeit lang produzierten Prisma-Deployments auf Vercel Bundles von über 40MB. Das hat sich mit Prisma Accelerate und den neueren Engine-Optionen erheblich verbessert, aber du kämpfst immer noch mit einem Gewichtsnachteil. Cold Starts bei Serverless-Funktionen waren bei einem Seahawk-Fintech-Projekt, das wir Ende 2023 ausgeliefert haben, deutlich langsamer. Wir haben es gemessen: etwa 800ms Cold Start mit Prisma versus unter 200ms, nachdem wir diesen spezifischen Service zu Drizzle migriert haben.
Drizzle ist winzig. Wirklich beschämend klein. Keine Binär-Engine. Keine Runtime-Code-Generierung. Es wird zu minimalem JavaScript kompiliert und dein Deployment bleibt schlank. Für Edge-Runtimes ist das derzeit die offensichtliche Wahl.
Das heißt, wenn du einen traditionellen Node.js-Server betreibst (Express, Fastify, eine Standard-Next.js-App auf einem gewöhnlichen VPS), spielt dieser Unterschied viel weniger Rolle. Ein persistenter Connection Pool kümmert sich nicht um Cold Starts.
---
Developer Experience: Wo Prisma immer noch gewinnt
Ich will ehrlich sein. Prismas DX ist schwer zu schlagen.
Die Schema-Datei ist wirklich angenehm zu bearbeiten. Migrationen werden mit prisma migrate dev durchgeführt und es funktioniert einfach. Prisma Studio (die GUI) hat mir Stunden gespart, in denen ich mich durch das Supabase-Dashboard kämpfen musste, wenn ich schnell Daten inspizieren musste. Und die TypeScript-Typen, die aus dem generierten Client herauskommen, sind gründlich. Du bekommst Autocompletion bei verschachtelten Relationen, bei where-Klauseln, bei select-Formen.
Drizzles TypeScript-Unterstützung ist auch ausgezeichnet, erfordert aber mehr anfängliche Überlegung. Du schreibst dein Schema in TypeScript-Dateien, was ich philosophisch eigentlich bevorzuge. Keine separate .prisma-Syntax zum Lernen. Aber der Query Builder braucht etwas Gewöhnung. Dinge wie komplexe Joins mit Aggregationen sind nicht so intuitiv wie Prismas include-Syntax.
Schema-Migrationen: Ein echter Unterschied
Prisma generiert automatisch Migration-SQL-Dateien und verfolgt sie. Drizzle auch, mit drizzle-kit, aber der Workflow fühlt sich etwas manueller an. Du führst drizzle-kit generate:pg aus, bekommst eine SQL-Datei und wendest sie selbst an (oder nutzt drizzle-kit push für schnelles Prototyping). Weniger Magie, mehr Kontrolle.
Für Junior-Entwickler gewinnt Prisma hier jedes Mal. Für Solo-Entwickler, die genau verstehen wollen, welches SQL ausgeführt wird, ist Drizzle auf eine Weise befriedigend, Prisma nicht.
---
Raw Query Power und komplexe Szenarien
2019 gab mir ein Client ein Briefing, das extrem komplexe Aggregationen erforderte: laufende Summen, Window Functions, bedingtes Gruppieren. Ich nutzte damals Prisma und bin fast sofort an die Grenze gestoßen. Prismas queryRaw existiert, aber in eine ansonsten abstrahierte Codebasis Raw SQL zu werfen fühlt sich wie Betrug an, und du verlierst all deine Typsicherheit.
Drizzle macht das viel besser. Window Functions, CTEs, Lateral Joins: Es hat entweder einen First-Class-Builder dafür oder du kannst in SQL-Fragmente dropppen, ohne deinen TypeScript-Kontext zu verlieren. Für Supabase-Projekte mit wirklich komplexen Reporting- oder Analytics-Abfragen gibt dir Drizzle mehr Spielraum zum Wachsen.
Das heißt, 80% der CRUD-Anwendungen brauchen nichts davon. Falls dein Projekt „Benutzer erstellen Posts, Posts haben Kommentare" ist, sind Prismas ausdrucksstarke Relationsabfragen schneller zu schreiben und einfacher für andere Entwickler auf einen Blick zu lesen.
---
Wann du dich für welche Option entscheidest
Lass mich hier direkt sein, weil ich zu viele Menschen gesehen habe, die sich verrenken beim Versuch, die „objektiv richtige" Antwort zu finden.
Wähle Drizzle, wenn:
- Du zu Edge- oder Serverless-Runtimes deployst, wo Bundle-Größe und Cold Starts relevant sind
- Dein Team sich mit SQL auskennt und du Transparenz darüber haben willst, welche Abfragen tatsächlich laufen
- Das Projekt hat komplexe Abfrageanforderungen (Berichte, Analysen, nicht standardisierte Aggregationen)
- Du bist ein einzelner Entwickler oder ein kleines Team, das minimalen Abstraktionsaufwand möchte
Wähle Prisma, wenn:
- Du ein traditionelles serverseitiges Node.js-Setup mit Connection Pooling betreibst
- Dein Team Junior-Entwickler hat, die vom geführten Schema-First-Workflow profitieren
- Das Projekt ist CRUD-lastig und die relationale Komplexität ist moderat
- Du möchtest ein ausgereiftes Ökosystem mit mehr Tools von Drittanbietern, Beispielen und Stack-Overflow-Antworten
Noch eine Sache, die erwähnenswert ist: Die Dokumentation von Prisma ist besser. Deutlich besser. Drizels Dokumentation hat sich im letzten Jahr stark verbessert, aber Prisma hatte mehr Zeit, um Tutorials, Leitfäden und Community-Ressourcen aufzubauen. Wenn du beim Lernen mitgehst, ist dieser Unterschied real.
---
Praktische Setup-Hinweise speziell für Supabase
Egal wofür du dich entscheidest, einige Dinge gelten universell, wenn du dich mit Supabase verbindest.
- Nutze den Connection-Pooler-URI, nicht die direkte Verbindung. Supabase stellt einen Supabase-Connection-Pooler über PgBouncer bereit. Verwende für Serverless immer diesen. Der von Prisma empfohlene
DATABASE_URLfür Serverless sollte auf den Pooler-Endpunkt auf Port 6543 verweisen. - Deaktiviere vorbereitete Anweisungen, wenn du PgBouncer verwendest. Prisma benötigt
?pgbouncer=truean die URL angehängt. Drizzle benötigtprepare: falsein der Postgres.js- oder node-postgres-Konfiguration. Wenn du das überspringst, bekommst du in der Produktion kryptische Fehler. - RLS ist dein Freund, aber du musst Sessions konfigurieren. Wenn du möchtest, dass RLS-Richtlinien auf ORM-Abfragen zutreffen, musst du die Postgres-Rolle und den JWT-Anspruch auf Sitzungsebene festlegen. Das ist ein Boilerplate, das du nicht umsonst bekommst.
- Arbeite nicht gegen die Stärken von Supabase. Nutze
supabase-jsfür Authentifizierung, Echtzeit und Speicher. Nutze dein ORM für komplexe Datenabfragen, bei denen die Filterung des Supabase-Clients zu kurz greift. Sie können im selben Projekt koexistieren.
---
FAQ
Ist Drizzle 2024 produktionsreif?
Ja. Es wird in der Produktion von Teams in Unternehmen verwendet, die nicht nur Wochenend-Nebenprojekte sind. Die API ist seit Ende 2023 stabil genug für ernsthafte Arbeiten. Ich würde Prisma immer noch als „kampfgetestet" bezeichnen, einfach weil es älter ist, aber Drizzle ist kein Risiko mehr.
Kann ich beide im selben Projekt verwenden?
Technisch ja. Wir haben das kurzzeitig genau so getan (versehentlich, nicht als Strategie). Tu das nicht. Der kognitive Aufwand lohnt sich nicht, und zwei verschiedene Migrationssysteme, die die gleiche Datenbank berühren, sind ein Rezept für einen schlechten Tag. Wähle eins.
Funktioniert Prisma mit Supabase Edge Functions?
Prisma und Supabase Edge Functions (die auf Deno laufen) haben eine komplizierte Beziehung gehabt. Prismas Engine läuft nicht nativ in Deno. Die Verwendung von Prisma Accelerate oder einem externen Pooling-Setup kann diese umgehen, aber es bringt zusätzliche bewegliche Teile mit sich. Drizzle hat in Deno-Umgebungen keine solchen Probleme.
Was ist mit Typsicherheit? Sind sie vergleichbar?
Beide generieren TypeScript-Typen und beide integrieren sich gut in TypeScript-Projekte. Drizels Typen werden aus deinen TypeScript-Schemadefinitionen abgeleitet. Prismas Typen kommen vom generierten Client. Nach meiner Erfahrung sind Prismas Typen für verschachtelte Relationen aus der Box etwas ergonomischer, aber Drizels Inferenz hat erheblich aufgeholt.
Welches ist bei der Laufzeit schneller?
Drizzle hat einen echten Performance-Vorteil, weil es weniger Runtime-Overhead zwischen deiner Abfrage und dem Postgres-Wire-Protokoll gibt. In Benchmarks ist der Unterschied messbar. In den meisten echten Anwendungen wird er von der Netzwerklatenz zu deiner Datenbank in den Schatten gestellt. Wähle ein ORM nicht hauptsächlich wegen der rohen Abfragegeschwindigkeit.
---
Die tatsächliche Antwort
Drizzle für Edge/Serverless-Supabase-Projekte oder überall dort, wo du nah an der Hardware arbeiten möchtest. Prisma für Team-Umgebungen, CRUD-lastige Apps und Situationen, in denen die Onboarding-Geschwindigkeit von Entwicklern wichtig ist.
Ich nutze Drizzle inzwischen häufiger als noch vor einem Jahr. Aber ich bereue die Jahre mit Prisma nicht. Es hat mich zu einem besseren Entwickler gemacht, auch weil es dogmatisch genug war, dass ich verstehen musste, warum ich an seine Grenzen stieß.
Keines von beiden wird über dein Projekt entscheiden. Dein Schema-Design wird es tun. Deine Indexierungs-Entscheidungen werden es tun. Wähle das, das zu deinem Team passt, und fang an zu bauen.