Prisma vs Drizzle : confort ou contrôle pour ton ORM TypeScript ?

La question ORM du moment en TypeScript

Si on construit quoi que ce soit avec TypeScript et une base relationnelle, on est déjà tombé sur cette décision. Prisma a construit la catégorie. Il a rendu le travail de base de données accessible pour toute une génération de développeurs TypeScript. Drizzle est arrivé et a remis en question les hypothèses sur lesquelles Prisma était construit.

Ce n'est pas un "lequel est objectivement meilleur". C'est une question sur ce qu'on valorise : le confort et l'abstraction, ou le contrôle et la transparence. On a des opinions. Allons-y.

Ce que Prisma fait bien

Le plus gros atout de Prisma, c'est le fichier prisma.schema. C'est une source de vérité unique pour le modèle de données, et c'est franchement lisible. On définit les modèles, les relations et les enums en un seul endroit. Tout en découle : le client généré, les migrations, les types.

Ce fichier de schéma compte plus qu'on ne lui accorde de crédit. Quand un nouveau développeur rejoint l'équipe, il ouvre prisma.schema et voit immédiatement la forme de la base de données. Pas besoin de fouiller dans des fichiers TypeScript éparpillés. Pas de devinettes sur la structure des tables.

Prisma Migrate gère les migrations avec un historique linéaire de fichiers SQL. Il génère le SQL à partir des changements de schéma, suit ce qui a été appliqué et gère la danse habituelle create/alter/drop. Ce n'est pas parfait -- parfois le SQL généré n'est pas celui qu'on écrirait à la main -- mais ça marche et c'est prévisible.

Prisma Studio donne une GUI pour parcourir et éditer les données. Ça a l'air mineur jusqu'au moment où on debug un problème de prod et qu'on a besoin de vérifier rapidement si un enregistrement existe. Ce n'est pas un remplacement pour un vrai client de base de données, mais c'est un bonus appréciable livré gratuitement.

Les types TypeScript générés depuis le schéma sont excellents. L'autocomplétion marche. Si on se trompe de nom de champ, l'éditeur le voit. Si on ajoute un include pour une relation, le type de retour se met à jour automatiquement. C'est la partie de Prisma qui convertit les sceptiques.

Et l'écosystème autour est large. Prisma Accelerate ajoute du connection pooling et du cache à l'edge. Prisma Pulse donne des change streams temps réel. Il y a des adaptateurs pour Neon, PlanetScale, Turso et d'autres. Des tutos, des templates de démarrage, des réponses StackOverflow -- on sera rarement coincé sans référence.

Ce que Drizzle fait bien

Drizzle prend une approche fondamentalement différente. Le schéma est défini en TypeScript pur, pas dans un DSL custom. Les fichiers de schéma sont juste des fichiers .ts qu'on peut importer, composer et refactoriser comme n'importe quel autre code.

Le truc qui rend les développeurs Drizzle évangéliques : l'API de requête ressemble à du SQL. Quand on écrit une requête Drizzle, on peut lire le SQL qu'elle va générer juste en regardant le code. db.select().from(users).where(eq(users.email, email)) se lit presque exactement comme SELECT * FROM users WHERE email = ?.

Ce n'est pas un accident. Drizzle a été conçu pour que la traduction mentale entre le code et la requête base de données soit la plus courte possible. Pour les développeurs qui connaissent déjà SQL, ça signifie moins de surprises et moins de temps passé à se demander ce que l'ORM fait réellement.

Il n'y a pas d'étape de codegen. On ne lance pas une commande generate pour attendre qu'un client se construise. Le schéma est le code. Les types sont inférés directement des définitions de tables. Ça rend la boucle de feedback plus serrée et élimine toute une catégorie de bugs "j'ai oublié de regénérer".

L'empreinte runtime est plus légère aussi. Prisma embarque un moteur de requêtes binaire (écrit en Rust) qui tourne à côté de l'app. Drizzle, non -- c'est juste une librairie JavaScript qui construit des chaînes SQL et les envoie au driver de base de données. Moins de machinerie, moins de pièces mobiles.

Drizzle a aussi une API de requêtes relationnelles qui gère l'eager loading de données liées. C'est pas aussi automatique que le include de Prisma, mais ça donne un contrôle plus explicite sur ce qui est fetché et comment.

Pour les migrations, drizzle-kit propose deux workflows : drizzle-kit generate crée des fichiers de migration SQL à partir des diffs de schéma (similaire à Prisma Migrate), et drizzle-kit push applique les changements de schéma directement en base sans fichiers de migration. Le workflow push est top pour le prototypage. Le workflow generate c'est ce qu'on veut en production.

La différence de modèle mental

C'est le vrai embranchement.

La philosophie de Prisma : on ne devrait pas avoir besoin de penser en SQL. On définit le schéma, on utilise le client, et on laisse l'ORM gérer les requêtes. L'abstraction est le produit.

La philosophie de Drizzle : on devrait toujours savoir quel SQL tourne. On écrit des requêtes qui correspondent au SQL, et on garde l'abstraction assez fine pour qu'il n'y ait pas de couche mystère entre nous et la base.

Les deux sont valides. Mais elles attirent des types de développeurs différents et créent des types de problèmes différents.

Avec Prisma, le pain point classique c'est le N+1 qu'on n'a pas vu venir, ou la jointure que Prisma transforme en requêtes multiples quand on en attendait une seule. L'abstraction cache parfois des choses qu'on aurait préféré voir.

Avec Drizzle, le pain point classique c'est plus de boilerplate. On écrit plus de code pour exprimer des choses que Prisma gérerait implicitement. Le prix de la transparence, c'est la verbosité.

Performance au runtime

Drizzle est généralement plus léger au runtime. Pas de binaire moteur de requêtes, pas de processus supplémentaire, juste une librairie qui construit du SQL et l'envoie via un driver de base de données. Pour les déploiements serverless et edge, c'est un vrai avantage. Les cold starts sont plus rapides parce qu'il y a moins à charger.

Prisma s'est amélioré ici. Le proxy Accelerate gère le connection pooling et le cache de requêtes, ce qui aide beaucoup en environnement serverless. Ils ont aussi livré des clients edge-compatibles qui marchent avec Cloudflare Workers et Vercel Edge Functions. Mais le moteur de requêtes fait toujours partie de l'histoire, et ça ajoute du poids.

Si on déploie sur un serveur ou container classique, la différence de performance est négligeable pour la plupart des apps. Si on déploie sur des edge functions ou du serverless avec des budgets de cold start serrés, Drizzle a un avantage structurel.

L'histoire edge et serverless

Drizzle marche bien avec les drivers serverless récents : Cloudflare D1, Turso (libSQL), le driver serverless de Neon, et Vercel Postgres. Ces intégrations se sentent first-class parce que l'architecture de Drizzle a été conçue avec elles en tête.

Prisma a ajouté le support edge, et ça marche, mais c'est arrivé plus tard. Le produit Accelerate est leur réponse au problème de connection pooling en serverless, et c'est solide. Mais si on construit spécifiquement sur D1 ou Turso, Drizzle se sent plus natif.

Pour les équipes qui déploient sur Vercel ou Railway, les deux ORM marchent bien. L'histoire edge ne compte que si on fait réellement tourner du code à l'edge.

Workflows de migration

Le workflow de migration de Prisma est opiniâtre : prisma migrate dev génère les fichiers de migration, prisma migrate deploy les applique. On commit les fichiers de migration dans le contrôle de version. C'est linéaire et prévisible.

Drizzle donne deux modes. drizzle-kit push est rapide et souple -- top pour le dev local et le prototypage, quand on veut juste que la base corresponde au schéma sans gérer des fichiers de migration. drizzle-kit generate crée des fichiers de migration SQL quand on a besoin de l'audit trail et de la sécurité en prod.

On aime avoir les deux options. L'approche unique de Prisma est plus simple, mais parfois on veut juste itérer sur un schéma sans générer une migration pour chaque retouche.

Maturité d'écosystème

Prisma a une communauté plus large, plus de tutos, plus de réponses StackOverflow et plus de templates de démarrage. Si on google un problème, on trouvera une réponse liée à Prisma plus vite. Ça compte pour l'onboarding d'équipe et pour les développeurs juniors qui apprennent encore.

La communauté de Drizzle grandit vite. Le Discord est actif, la documentation s'est nettement améliorée, et plus d'apps de production l'utilisent chaque mois. Mais c'est encore plus jeune. Si on tombe sur un edge case bizarre, on est peut-être le premier à le rencontrer.

Pour les équipes qui valorisent l'autonomie et sont à l'aise pour lire du code source quand la doc ne suffit pas, le plus petit écosystème de Drizzle est suffisant. Pour les équipes qui ont besoin que chaque question ait une réponse existante quelque part, l'avance de Prisma est réelle.

Quand choisir Prisma

• L'équipe a des niveaux d'expérience variés et on veut l'onboarding le plus rapide.
• On valorise un fichier de schéma unique et lisible comme source de vérité.
• On veut Prisma Studio pour parcourir les données rapidement pendant le développement.
• On a besoin du plus gros écosystème possible de tutos, d'exemples et de réponses communautaires.
• On construit un SaaS où la vitesse de développement compte plus que le contrôle au niveau des requêtes.
• On aime l'idée d'Accelerate et Pulse pour le cache et les features temps réel.

Quand choisir Drizzle

• L'équipe connaît bien SQL et veut des requêtes qui reflètent la syntaxe SQL.
• On déploie sur des edge functions ou du serverless et la taille du cold start compte.
• On ne veut pas d'étape de codegen : les changements de schéma se reflètent immédiatement dans les types.
• On préfère définir le schéma en TypeScript plutôt que dans un DSL custom.
• On utilise D1, Turso ou le driver serverless de Neon et on veut un support first-class.
• On valorise une abstraction fine et on veut voir exactement quelles requêtes touchent la base.
• On veut à la fois le push (itération rapide) et le generate (migrations de prod).

Verdict

Prisma est le choix par défaut le plus sûr pour la plupart des équipes. L'outillage est plus soigné, l'écosystème est plus gros, et l'histoire d'onboarding est plus forte. Si on construit une app Next.js avec une base Postgres et qu'on veut avancer vite, Prisma servira bien.

Drizzle est le meilleur choix pour les équipes avec de solides instincts SQL qui veulent moins de surprises. Si les gens qui écrivent du code de base de données dans l'équipe n'aiment pas les abstractions lourdes, Drizzle les rendra plus heureux et plus productifs. Le runtime plus léger en fait aussi le meilleur pick pour les architectures edge-first.

Aucun n'est le mauvais choix. Mais ils sont construits sur des croyances différentes sur ce que devrait faire un ORM, et choisir celui qui correspond aux instincts de l'équipe épargnera de la friction aussi longtemps qu'on l'utilise.