Prisma 6 : pourquoi c'est notre ORM de référence

01Schema as source of truth

Le schema.prisma décrit la structure de la base de manière déclarative dans un DSL spécifique (mais très lisible). Les types TypeScript du client Prisma sont générés automatiquement, les migrations SQL aussi. La duplication entre code applicatif et structure de base est éliminée. Quand vous ajoutez une colonne, vous modifiez le schema, vous régénérez le client (prisma generate), et toutes les références dans votre code TypeScript savent qu'elle existe — type checking + autocomplétion + refactoring serein.

// schema.prisma
model Post {
  id        String   @id @default(cuid())
  title     String
  content   String   @db.Text
  status    PostStatus @default(DRAFT)
  authorId  String
  author    User     @relation(fields: [authorId], references: [id])
  tags      Tag[]    @relation("PostTags")
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt

  @@index([authorId])
  @@index([status, createdAt])
}

enum PostStatus {
  DRAFT
  PUBLISHED
  ARCHIVED
}

02Typage strict de bout en bout

Une requête `prisma.post.findMany({ include: { author: true } })` retourne un type qui inclut l'objet auteur. Si vous omettez `include`, le type le sait : impossible d'accéder à `post.author` par erreur. Refactoring infiniment plus serein. Combinée avec strict mode TypeScript et noUncheckedIndexedAccess, cette discipline élimine pratiquement les erreurs runtime liées aux requêtes DB. Sur nos projets, on ne voit pratiquement jamais d'erreur SQL en production qui ne soit pas une erreur métier — pas une erreur de typage.

const posts = await prisma.post.findMany({
  where: { status: 'PUBLISHED' },
  include: { author: { select: { name: true } } },
  orderBy: { createdAt: 'desc' },
  take: 10
})
// posts est typé : Array<{
//   id: string, title: string, ...,
//   author: { name: string }
// }>

03Migrations sûres avec Prisma Migrate

Prisma Migrate génère automatiquement les migrations SQL à partir des changements de schema. Trois commandes pratiques : `prisma migrate dev` pour développer (génère + applique en local), `prisma migrate deploy` pour déployer (applique sans générer, idempotent en CI/CD), `prisma migrate reset` pour tout réinitialiser en dev. Les fichiers SQL générés sont versionnés dans Git, lisibles, et modifiables si besoin (pour ajouter du SQL custom non-supporté par le DSL Prisma).

04Nouveautés Prisma 6 et 7

Prisma 6 apporte : meilleure perf sur les gros datasets (jusqu'à 30% plus rapide sur findMany avec relations), support natif de PostgreSQL 16+ (JSON path queries, partitionnement), Prisma Accelerate (caching distribué edge-side, transparent dans le code). Prisma 7 (sortie 2026) introduit le client edge runtime natif (avant on devait passer par Prisma Accelerate), et un meilleur support multi-schema PostgreSQL pour les architectures multi-tenant. Sur les projets serverless (Vercel, Cloudflare Workers), Prisma 7 + Accelerate = stack pratiquement parfaite.

05Patterns avancés : transactions et middleware

Pour les opérations multi-table atomiques, Prisma supporte les transactions interactives. Pour ajouter de la logique transversale (logging, soft delete, audit trail), les Prisma Client Extensions (anciennement middleware) permettent d'intercepter les requêtes. Pattern qu'on utilise : un extension qui ajoute automatiquement `userId` aux WHERE des requêtes pour le multi-tenancy, et qui filtre les soft-deleted records.

// Soft delete via extension
const prisma = new PrismaClient().$extends({
  query: {
    $allModels: {
      async findMany({ args, query }) {
        args.where = { ...args.where, deletedAt: null }
        return query(args)
      },
      async delete({ args, model }) {
        return prisma[model].update({
          where: args.where,
          data: { deletedAt: new Date() }
        })
      },
    },
  },
})

06Quand Prisma n'est PAS le bon choix

Pour des requêtes très complexes (window functions, CTE récursives, requêtes analytiques sur gros datasets), le SQL brut via postgres.js ou pgTyped reste préférable. Prisma supporte $queryRaw / $executeRaw pour ces cas, mais on perd le typage automatique. Sur les projets edge-only (Cloudflare Workers, Vercel Edge), Drizzle peut être un meilleur fit pour la taille du bundle (~30KB Drizzle vs ~150KB Prisma client). Pour les apps qui ont besoin de mapping ORM très custom (héritage avancé, polymorphisme), TypeORM ou Sequelize peuvent être préférables. Pour le SQL pur sans aucune abstraction, postgres.js est l'option la plus directe.

07Comparaison rapide avec Drizzle (le concurrent montant)

Drizzle est l'alternative qui monte en 2024-2026. Avantages Drizzle : bundle 5x plus léger, syntaxe SQL-like (moins d'apprentissage pour les DBA), excellent support edge runtime. Avantages Prisma : DSL schema plus lisible, Prisma Studio (UI d'admin gratuit), écosystème plus mature, support Prisma Pulse pour le real-time, et migrations plus robustes. Pour 95% de nos projets, Prisma reste préférable. Pour les apps Cloudflare Workers ultra-optimisées, Drizzle prend l'avantage. On utilise les deux selon le contexte.