Le printemps dernier j'étais trois semaines dans un projet SaaS secondaire, avais Supabase câblé, et fixais une bifurcation : Drizzle ou Prisma. J'avais utilisé Prisma sur probablement quarante plus projets clients chez Seahawk. Territoire confortable. Mais un développeur junior sur le projet ne cessait de pousser pour Drizzle, et honnêtement j'étais un peu méfiant au départ. « C'est plus récent. Moins prouvé. Allons-y juste Prisma. »
J'ai eu tort d'écarter ça aussi vite.
On a fini par essayer les deux sur différentes parties du même codebase (désordonné, oui, mais instructif). Ce que j'ai appris a changé comment je pense au choix d'ORM entièrement. Si vous construisez sur Supabase et vous êtes vraiment incertain lequel choisir, c'est le post que j'aurais souhaité avoir.
---
Ce Que Vous Choisissez Vraiment
Ces deux outils résolvent le même problème en surface : vous ne voulez pas écrire du SQL brut chaque fois que vous touchez la base de données. Mais ils viennent de philosophies très différentes.
Prisma traite votre schéma comme la source unique de vérité. Vous définissez un fichier schema.prisma, lancez prisma generate, et obtenez un client complètement typé. Ça abstrait le SQL presque entièrement. Vous pensez rarement en tables et jointures ; vous pensez en modèles et relations.
Drizzle s'assoit beaucoup plus près du SQL. Votre schéma est défini en TypeScript, vos requêtes ressemblent à du SQL, et il n'y a pas de client séparé généré par CLI assis au milieu. C'est décrit comme une « ORM TypeScript qui se sent comme du SQL » et c'est véritablement exact.
Aucun n'est objectivement meilleur. Point final. Le choix dépend de votre équipe, vos motifs de requête, et combien vous faites confiance aux propres outils de Supabase pour faire le gros du travail.
---
Le Contexte Supabase Change Tout
Voici la chose que la plupart des posts de comparaison ratent : Supabase n'est pas une base de données Postgres vierge. Ça vient avec Row Level Security, des souscriptions en temps réel, des API REST et GraphQL auto-générées, et son propre client JavaScript. Vous faites souvent déjà beaucoup via supabase-js avant même de toucher à un ORM.
La vraie question n'est donc pas juste « quel ORM est meilleur ? ». C'est « quelle part de ma logique de requête doit passer par un ORM par rapport au client Supabase directement ? »
J'ai vu des équipes choisir Prisma, ignorer supabase-js presque entièrement, et ensuite se demander pourquoi leurs stratégies RLS ne s'activent pas. C'est parce que Prisma se connecte directement à Postgres via la chaîne de connexion. Il contourne la couche PostgREST de Supabase. Vos règles RLS ? Elles ne s'appliquent que si vous dites à Prisma de SET LOCAL role = authenticated au niveau de la session. Ce n'est pas difficile à configurer, mais il faut savoir que c'est une chose.
Drizzle a le même problème. Connexion directe à Postgres, même comportement de contournement. Mais parce que Drizzle se sent plus natif à SQL, les développeurs ont tendance à être plus conscients qu'ils parlent directement à Postgres, pas à travers l'abstraction Supabase.
---
Taille du Bundle et Démarrages à Froid : L'Argument Serverless
Si vous déployez sur Vercel Edge Functions, Cloudflare Workers, ou même des Vercel Serverless Functions standard, la taille du bundle est une vraie préoccupation.
Le client généré par Prisma est... volumineux. Le moteur de requête seul est un binaire qui est regroupé avec votre déploiement. Pendant un temps, les déploiements Prisma sur Vercel produisaient des bundles de plus de 40 Mo. Ils ont amélioré cela significativement avec Prisma Accelerate et les nouvelles options de moteur, mais vous combattez toujours un désavantage de poids. Les démarrages à froid sur les fonctions serverless étaient noticeablement plus lents sur un projet fintech Seahawk que nous avons livré fin 2023. Nous l'avons mesuré : environ 800 ms de démarrage à froid avec Prisma contre moins de 200 ms après que nous ayons migré ce service spécifique vers Drizzle.
Drizzle est minuscule. Comme, embarrassamment petit. Pas de moteur binaire. Pas de génération de code à l'exécution. Il se compile en JavaScript minimal et votre déploiement reste allégé. Pour les runtimes edge, c'est le choix évident en ce moment.
Cela dit, si vous exécutez un serveur Node.js traditionnel (Express, Fastify, une app Next.js standard sur un VPS ordinaire), cet écart importe beaucoup moins. Un pool de connexion persistant ne se soucie pas des démarrages à froid.
---
Expérience Développeur : Où Prisma Gagne Encore
Je vais être honnête. L'expérience développeur de Prisma est difficile à battre.
Le fichier de schéma est genuinely agréable à utiliser. Les migrations sont gérées par prisma migrate dev et ça fonctionne tout simplement. Prisma Studio (l'interface graphique) m'a fait gagner des heures à fouiller dans le tableau de bord Supabase quand j'ai besoin d'inspecter rapidement des données. Et les types TypeScript qui sortent du client généré sont complets. Vous obtenez l'autocomplétion sur les relations imbriquées, sur les clauses where, sur les formes select.
Le support TypeScript de Drizzle est aussi excellent, mais il nécessite plus de réflexion en amont. Vous écrivez votre schéma dans des fichiers TypeScript, ce que je préfère philosophiquement. Pas de syntaxe .prisma séparée à apprendre. Mais le générateur de requête prend du temps à s'habituer. Des choses comme les jointures complexes avec agrégats ne sont pas aussi intuitives que la syntaxe include de Prisma.
Migrations de Schéma : Une Vraie Différence
Prisma génère automatiquement les fichiers SQL de migration et les suit. Drizzle aussi, avec drizzle-kit, mais le flux de travail se sent un peu plus manuel. Vous exécutez drizzle-kit generate:pg, obtenez un fichier SQL, et l'appliquez vous-même (ou utilisez drizzle-kit push pour le prototypage rapide). Moins de magie, plus de contrôle.
Pour les développeurs juniors, Prisma gagne ici chaque fois. Pour les développeurs solo qui veulent comprendre exactement quel SQL s'exécute, Drizzle est satisfaisant d'une manière que Prisma ne l'est pas.
---
Puissance de Requête Brute et Scénarios Complexes
En 2019, un client m'a confié un brief qui nécessitait des agrégations extrêmement complexes : totaux cumulés, fonctions de fenêtre, regroupement conditionnel. J'utilisais Prisma à l'époque et j'ai atteint la limite presque immédiatement. Le queryRaw de Prisma existe, mais descendre dans du SQL brut au milieu d'une base de code autrement abstraite se sent comme tricher, et vous perdez toute sécurité de type.
Drizzle gère cela tellement mieux. Fonctions de fenêtre, CTE, jointures latérales : il a soit un générateur de première classe pour eux, soit vous pouvez descendre dans des fragments SQL sans perdre votre contexte TypeScript. Pour les projets Supabase avec de vraies requêtes de rapports ou analytiques complexes, Drizzle vous donne plus de marge de manœuvre.
Cela dit, 80 % des applications CRUD n'ont besoin d'aucune de ces choses. Si votre projet est « les utilisateurs créent des articles, les articles ont des commentaires », les requêtes de relations expressives de Prisma sont plus rapides à écrire et plus faciles pour les autres développeurs à lire d'un coup d'œil.
---
Quand choisir l'un ou l'autre
Je vais être direct à ce sujet, parce que j'ai vu trop de gens se compliquer la tâche en essayant de trouver la réponse « objectivement correcte ».
Choisissez Drizzle si :
- Vous déployez sur des runtimes edge ou serverless où la taille du bundle et les démarrages à froid importent
- Votre équipe est à l'aise avec SQL et vous voulez de la transparence sur les requêtes réellement exécutées
- Le projet a des exigences de requête complexes (rapports, analytique, agrégations non standard)
- Vous êtes un développeur solo ou une petite équipe qui souhaite une surcharge d'abstraction minimale
Choisissez Prisma si :
- Vous exécutez une configuration Node.js traditionnelle côté serveur avec un regroupement de connexions
- Votre équipe compte des développeurs juniors qui bénéficient du workflow guidé en schéma d'abord
- Le projet est à forte charge CRUD et la complexité relationnelle est modérée
- Vous souhaitez un écosystème mature avec plus d'outils tiers, d'exemples et de réponses Stack Overflow
Une autre chose qui vaut le coup d'être mentionnée : la documentation de Prisma est meilleure. Substantiellement. La documentation de Drizzle s'est beaucoup améliorée au cours de la dernière année, mais Prisma a eu plus de temps pour construire des tutoriels, des guides et des ressources communautaires. Si vous apprenez en chemin, cet écart est réel.
---
Notes de configuration pratiques pour Supabase spécifiquement
Quel que soit votre choix, quelques éléments s'appliquent universellement lors de la connexion à Supabase.
- Utilisez l'URI du pool de connexion, pas la connexion directe. Supabase fournit un pool de connexion Supabase via PgBouncer. Pour le serverless, utilisez toujours celui-ci. L'URL
DATABASE_URLrecommandée de Prisma pour le serverless doit pointer vers le point de terminaison du pool sur le port 6543. - Désactivez les déclarations préparées lors de l'utilisation de PgBouncer. Prisma nécessite
?pgbouncer=trueajouté à l'URL. Drizzle nécessiteprepare: falsedéfini dans la configuration Postgres.js ou node-postgres. Ignorez cela et vous obtiendrez des erreurs énigmatiques en production. - RLS est votre ami mais vous devez configurer les sessions. Si vous souhaitez que les politiques RLS s'appliquent aux requêtes ORM, vous devrez définir le rôle Postgres et la réclamation JWT au niveau de la session. Ce n'est pas du code passe-partout que vous obtenez gratuitement.
- Ne combattez pas les forces de Supabase. Utilisez
supabase-jspour l'authentification, le temps réel et le stockage. Utilisez votre ORM pour les requêtes de données complexes où le filtrage du client Supabase est insuffisant. Ils peuvent coexister dans le même projet.
---
FAQ
Drizzle est-il prêt pour la production en 2024 ?
Oui. Il est utilisé en production par des équipes dans des entreprises qui ne sont pas que des projets secondaires de week-end. L'API a été suffisamment stable pour un travail sérieux depuis la fin de 2023. J'appellerais toujours Prisma plus « battle-tested » simplement en raison de l'ancienneté, mais Drizzle n'est plus un risque.
Puis-je utiliser les deux dans le même projet ?
Techniquement oui. Nous avons fait exactement cela brièvement (accidentellement, pas comme stratégie). Ne le faites pas. La surcharge cognitive n'en vaut pas la peine, et avoir deux systèmes de migration différents touchant la même base de données est une invocation du pire. Choisissez-en un.
Prisma fonctionne-t-il avec les Supabase Edge Functions ?
Prisma et les Supabase Edge Functions (qui s'exécutent sur Deno) ont eu une relation compliquée. Le moteur de Prisma ne s'exécute pas nativement dans Deno. L'utilisation de Prisma Accelerate ou d'une configuration de pooling externe peut contourner ce problème, mais cela ajoute des pièces mobiles. Drizzle n'a pas de tels problèmes dans les environnements Deno.
Qu'en est-il de la sécurité des types ? Sont-ils comparables ?
Les deux génèrent des types TypeScript et s'intègrent bien aux projets TypeScript. Les types de Drizzle sont dérivés de vos définitions de schéma TypeScript. Les types de Prisma proviennent du client généré. À mon avis, les types de relation imbriqués de Prisma sont légèrement plus ergonomiques dès le départ, mais l'inférence de Drizzle a considérablement rattrapé son retard.
Lequel est plus rapide à l'exécution ?
Drizzle a un véritable avantage en matière de performance car il y a moins de surcharge d'exécution entre votre requête et le protocole Postgres. Dans les benchmarks, la différence est mesurable. Dans la plupart des applications réelles, elle est éclipsée par la latence réseau de votre base de données. Ne choisissez pas un ORM principalement pour la vitesse brute des requêtes.
---
La Vraie Réponse
Drizzle pour les projets edge/serverless Supabase, ou partout où vous voulez rester au plus proche du métal. Prisma pour les environnements d'équipe, les applications heavy CRUD, et les situations où la vitesse d'onboarding des développeurs compte.
J'utilise Drizzle plus maintenant qu'il y a un an. Mais je ne regrette pas les années passées avec Prisma. Cela m'a rendu meilleur développeur, en partie parce qu'il était assez opinionated que j'ai dû comprendre pourquoi je heurtais ses limites.
Aucun des deux ne fera ou défait votre projet. La conception de votre schéma le fera. Vos décisions d'indexation le feront. Choisissez celui qui convient aux personnes de votre équipe et commencez à construire.