Drizzle vs Prisma: por qué usamos los dos en producción

Drizzle vs Prisma no es un empate para nosotros, pero tampoco hay un ganador. Usamos los dos en producción: Prisma sobre Postgres en aplicaciones de clientes más antiguas y Drizzle sobre Cloudflare D1 en cada app nueva desde que llevamos el trabajo nuevo a Workers. La respuesta corta: elija Drizzle cuando despliegue en un entorno serverless o edge y quiera el esquema y las migraciones como TypeScript y SQL puros; mantenga Prisma donde ya funciona.

La mayoría de las comparativas las escribe uno de los dos fabricantes o alguien que ha hecho una demo dos veces. Esta sale de repositorios que mantenemos, con la configuración tal como es.

Drizzle vs Prisma: ¿cuál es la diferencia real?

Los dos le dan un cliente de base de datos tipado en TypeScript. La diferencia está en dónde vive el esquema y en lo lejos que queda el ORM de SQL.

La documentación de Drizzle lo describe como "dialect-specific, slim, performant and serverless-ready by design" (Drizzle overview, consultado el 24/10/2026). Prisma es la herramienta de más alto nivel: usted describe los modelos y él decide el SQL.

¿Por qué las apps nuevas usan Drizzle?

Nuestras apps nuevas funcionan en Cloudflare Workers con D1, que es SQLite. Nuestra plantilla de inicio y nuestras herramientas internas comparten la misma configuración. Toda la configuración de Drizzle es esta:

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

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

El esquema es un archivo TypeScript. Recortado de nuestra plantilla:

// 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(),
})

El cliente es una línea sobre el binding de D1, y una consulta se lee como 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)

Tres motivos nos hicieron cambiar para el trabajo nuevo:

• El entorno de ejecución. El objetivo eran D1 y Workers. Drizzle se conecta con import { drizzle } from 'drizzle-orm/d1' (Drizzle y D1).
• El agente lee el esquema directamente. La mayor parte de nuestro código la escribe la IA, y un sénior responde de lo que corre en producción. Un esquema en TypeScript es simplemente código: el agente lo edita, el comprobador de tipos detecta al instante una columna equivocada y no hay ningún cliente generado que se olvide regenerar.
• Las migraciones son SQL en el PR. Quien revisa ve el ALTER TABLE exacto, no un diff de un archivo de modelo.

La autenticación usa la misma base de datos. Better Auth se conecta con drizzleAdapter(db, { provider: 'sqlite' }), así que los usuarios y las sesiones son tablas normales junto a las de la propia app.

¿Cómo llega un cambio de esquema a producción?

Un cambio sigue el mismo camino en cada app nueva. Nadie ejecuta SQL a mano contra producción.

La parte del despliegue está en nuestro código de infraestructura, escrito en TypeScript con Alchemy:

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

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

Una carpeta de archivos SQL es la historia de la base de datos. Eso es también lo que hace legible el traspaso para el siguiente ingeniero.

¿Dónde sigue ganando Prisma y por qué lo mantenemos?

Varias aplicaciones de clientes más antiguas usan Prisma sobre Postgres, en varias versiones mayores de Prisma. Una de ellas es el sistema que construimos y mantenemos para una empresa transitaria. La mayoría usa la configuración clásica: prisma-client-js, NextAuth con el adaptador de Prisma y prisma migrate deploy en el script de build, de modo que cada despliegue pone la base de datos al día antes de next build.

Esa configuración funciona. El lenguaje de modelos de Prisma es fácil de leer para alguien que no escribe SQL a diario, y su flujo de migraciones está maduro. No vemos motivo para quitarlo de una app que sirve bien a sus usuarios.

Cambiar de ORM toca a la vez cada consulta, cada test y cada migración, y el usuario no ve nada nuevo. Ese riesgo solo compensa cuando otra cosa lo obliga, como pasar a Workers. Cuando asumimos una app antigua, su ORM rara vez es lo primero que merece la pena arreglar. Cómo elegimos qué va primero lo explicamos en Deuda técnica: cómo medirla y qué corregir primero.

Una nota honesta más: el marketplace online de un cliente funciona con MongoDB y Mongoose, así que allí no hay ninguno de los dos ORM.

¿Qué cambió con Prisma 7?

Muchos artículos de "Drizzle vs Prisma" siguen discutiendo sobre el binario del motor en Rust. Ese argumento ahora pesa menos. Prisma ORM 7 se publicó el 19 de noviembre de 2025 con el "Rust-free Prisma Client as the default" (Prisma changelog, consultado el 24/10/2026). La guía de actualización dice:

La misma guía dice que ahora hace falta un driver adapter para cada base de datos. Así que Prisma 7 también funciona en Workers, y en D1 mediante @prisma/adapter-d1. La propia página de Prisma sobre D1 añade una advertencia que vale para cualquier ORM: D1 no admite transacciones, así que "implicit & explicit transactions will be ignored and run as individual queries" (Prisma y Cloudflare D1, consultado el 24/10/2026).

Con sinceridad: no hemos comparado el rendimiento de Drizzle con Prisma 7 ni hemos ejecutado Prisma 7 sobre D1. La mayoría de nuestras apps de Prisma siguen con prisma-client-js; la más nueva ya usa el nuevo generador prisma-client. Si compara los dos hoy, compare con Prisma 7, no con la versión de los artículos antiguos.

¿Drizzle o Prisma para su próxima app?

Repase los puntos. Cuantos más se cumplan en su caso, mejor encaja Drizzle:

Elija el que elija, mantenga las migraciones en el repositorio y aplíquelas desde el despliegue, nunca a mano. Si de todos modos se plantea una reescritura, lea primero ¿Refactorizar o reescribir desde cero? Cómo decidir.

¿Quiere una app web con una capa de datos que el siguiente ingeniero pueda leer?

Construimos aplicaciones web con este stack, Drizzle sobre D1 para el trabajo nuevo, y asumimos apps de Prisma sin reescribir lo que funciona: desarrollo de aplicaciones web a medida. La mayor parte de nuestro código la escribe la IA. Un sénior revisa cada cambio y responde de lo que corre en producción. Desde 2023 hemos entregado más de 15 proyectos en producción.

Le respondemos en un plazo de dos días laborables con algunas preguntas sobre su trabajo. Después acordamos qué hacemos primero.

Si prefiere hablar antes, reserve una llamada introductoria de 15 minutos.

¿Sobre qué ORM está discutiendo ahora mismo su equipo?

Preguntas frecuentes

¿Es Drizzle mejor que Prisma?

Ninguno es mejor en general. Drizzle encaja en entornos serverless y edge como Cloudflare Workers con D1, mantiene el esquema en TypeScript puro y se queda cerca de SQL. Prisma encaja en equipos que quieren un cliente de más alto nivel, su propio flujo de migraciones y herramientas como Prisma Studio, normalmente sobre Postgres.

¿Sigue necesitando Prisma un binario del motor en Rust?

No desde Prisma ORM 7, publicado el 19 de noviembre de 2025. El nuevo generador prisma-client usa un cliente sin Rust y necesita un driver adapter para cada base de datos. Las apps que siguen con prisma-client-js en Prisma 5 o 6 usan por defecto el motor en Rust.

¿Puede Prisma funcionar sobre Cloudflare D1?

Sí, mediante el driver adapter @prisma/adapter-d1. La documentación de Prisma advierte de que D1 no admite transacciones, así que las transacciones implícitas y explícitas se ejecutan como consultas individuales. El mismo límite de D1 vale para cualquier ORM.

¿Deberíamos migrar una app existente de Prisma a Drizzle?

Normalmente no. Reescribir la capa de datos de una app que funciona conlleva un riesgo real y no da nada nuevo a los usuarios. Pasamos a Drizzle cuando empezamos una app nueva o cuando cambia el entorno de ejecución, por ejemplo a Cloudflare Workers.

¿Cómo funcionan las migraciones de Drizzle?

Cambia el esquema en TypeScript, drizzle-kit generate escribe un archivo de migración en SQL puro y ese archivo se aplica en el despliegue. En nuestras apps, el archivo SQL pasa la revisión de código en el mismo PR que el cambio de esquema.