La primavera pasada estaba tres semanas dentro de un proyecto SaaS secundario, tenía Supabase conectado, y estaba mirando una encrucijada: Drizzle o Prisma. Había usado Prisma en probablemente más de cuarenta proyectos de clientes en Seahawk. Territorio cómodo. Pero un desarrollador junior en el proyecto seguía presionando por Drizzle, y honestamente fui un poco despectivo al principio. "Es más nuevo. Menos probado. Simplemente usemos Prisma."
Me equivoqué al desestimarlo tan rápido.
Terminamos probando ambos en diferentes partes de la misma base de código (desordenado, sí, pero instructivo). Lo que aprendí cambió completamente cómo pienso sobre la elección de ORM. Si estás construyendo en Supabase y genuinamente no estás seguro de cuál elegir, este es el artículo que desearía haber tenido.
---
Qué realmente estás eligiendo entre
Estas dos herramientas resuelven el mismo problema a nivel superficial: no quieres escribir SQL crudo cada vez que tocas la base de datos. Pero vienen de filosofías muy diferentes.
Prisma trata tu esquema como la única fuente de verdad. Defines un archivo schema.prisma, ejecutas prisma generate, y obtienes un cliente completamente tipado. Abstrae SQL casi completamente. Raramente piensas en tablas y uniones; piensas en modelos y relaciones.
Drizzle se sitúa mucho más cerca de SQL. Tu esquema se define en TypeScript, tus consultas se parecen a SQL, y no hay un cliente generado por CLI separado en el medio. Se describe como un "ORM de TypeScript que se siente como SQL" y eso es genuinamente preciso.
Ninguno es objetivamente mejor. Punto final. La elección depende de tu equipo, tus patrones de consulta, y cuánto confíes en las propias herramientas de Supabase para hacer el trabajo pesado.
---
El contexto de Supabase lo cambia todo
Aquí está lo que la mayoría de los artículos de comparación pierden: Supabase no es una base de datos Postgres en blanco. Viene con Row Level Security, suscripciones en tiempo real, APIs REST y GraphQL autogeneradas, y su propio cliente de JavaScript. A menudo ya estás haciendo mucho a través de supabase-js antes de tocar un ORM.
Entonces la verdadera pregunta no es solo "¿cuál ORM es mejor?" Es "¿cuánta de mi lógica de consultas debería pasar por un ORM versus el cliente de Supabase directamente?"
He visto equipos elegir Prisma, ignorar supabase-js casi por completo, y luego preguntarse por qué sus políticas RLS no se están activando. Es porque Prisma se conecta a Postgres directamente a través de la cadena de conexión. Evita la capa PostgREST de Supabase. ¿Tus reglas RLS? Solo se aplican si le dices a Prisma que SET LOCAL role = authenticated a nivel de sesión. No es difícil de configurar, pero tienes que saber que es una cosa.
Drizzle tiene el mismo problema. Conexión directa a Postgres, el mismo comportamiento de bypass. Pero como Drizzle se siente más nativo de SQL, los desarrolladores tienden a ser más conscientes de que están hablando con Postgres crudo, no a través de la abstracción de Supabase.
---
Tamaño del Bundle y Cold Starts: El Argumento Serverless
Si estás desplegando a Vercel Edge Functions, Cloudflare Workers, o incluso Vercel Serverless Functions estándar, el tamaño del bundle es una preocupación real.
El cliente generado por Prisma es... voluminoso. El motor de consultas solo es un binario que se agrupa con tu despliegue. Durante un tiempo, los despliegues de Prisma en Vercel producían bundles de más de 40MB. Mejoraron esto significativamente con Prisma Accelerate y las opciones de motor más nuevas, pero aún estás lidiando con una desventaja de peso. Los cold starts en funciones serverless fueron notablemente más lentos en un proyecto de fintech de Seahawk que enviamos a fines de 2023. Lo medimos: aproximadamente 800ms de cold start con Prisma versus menos de 200ms después de que migramos ese servicio específico a Drizzle.
Drizzle es diminuto. Como, vergonzosamente pequeño. Sin motor binario. Sin generación de código en tiempo de ejecución. Se compila a JavaScript mínimo y tu despliegue se mantiene ligero. Para tiempos de ejecución edge, es la opción obvia en este momento.
Dicho esto, si estás ejecutando un servidor Node.js tradicional (Express, Fastify, una aplicación Next.js estándar en un VPS regular), esta brecha importa mucho menos. Un grupo de conexiones persistente no se preocupa por los cold starts.
---
Experiencia del Desarrollador: Donde Prisma Aún Gana
Seré honesto. La DX de Prisma es difícil de superar.
El archivo de esquema es genuinamente agradable de usar. Las migraciones se manejan con prisma migrate dev y simplemente funciona. Prisma Studio (la GUI) me ha ahorrado horas de curiosidad en el panel de Supabase cuando necesito inspeccionar datos rápidamente. Y los tipos de TypeScript que salen del cliente generado son exhaustivos. Obtienes autocompletado en relaciones anidadas, en cláusulas where, en formas select.
El soporte de TypeScript de Drizzle también es excelente, pero requiere más pensamiento inicial. Escribes tu esquema en archivos TypeScript, que en realidad prefiero filosóficamente. Sin sintaxis .prisma separada para aprender. Pero el generador de consultas requiere acostumbrarse. Cosas como joins complejos con agregados no son tan intuitivas como la sintaxis include de Prisma.
Migraciones de Esquema: Una Diferencia Real
Prisma genera archivos SQL de migración automáticamente y los rastrea. Drizzle también, con drizzle-kit, pero el flujo de trabajo se siente un poco más manual. Ejecutas drizzle-kit generate:pg, obtienes un archivo SQL, y lo aplicas tú mismo (o usas drizzle-kit push para prototipado rápido). Menos magia, más control.
Para desarrolladores junior, Prisma gana aquí cada vez. Para desarrolladores solitarios que quieren entender exactamente qué SQL se está ejecutando, Drizzle es satisfactorio de una manera que Prisma no lo es.
---
Poder de Consultas Raw y Escenarios Complejos
En 2019, un cliente me presentó una tarea que requería agregaciones extremadamente complejas: totales en ejecución, funciones de ventana, agrupamiento condicional. Estaba usando Prisma en ese momento e inmediatamente llegué al límite. queryRaw de Prisma existe, pero descender a SQL crudo dentro de una base de código abstracta se siente como hacer trampa, y pierdes toda la seguridad de tipos.
Drizzle maneja esto mucho mejor. Funciones de ventana, CTEs, lateral joins: tiene un generador de primera clase para ellos o puedes descender a fragmentos SQL sin perder tu contexto de TypeScript. Para proyectos de Supabase con consultas de reportes o análisis genuinamente complejas, Drizzle te da más espacio para crecer.
Dicho esto, el 80% de las aplicaciones CRUD no necesitan nada de esto. Si tu proyecto es "los usuarios crean publicaciones, las publicaciones tienen comentarios", las consultas de relación expresivas de Prisma son más rápidas de escribir y más fáciles para que otros desarrolladores lean de un vistazo.
---
Cuándo elegir cada una
Permíteme ser directo sobre esto, porque he visto a demasiadas personas enredarse en nudos tratando de encontrar la respuesta "objetivamente correcta".
Elige Drizzle si:
- Estás desplegando en tiempos de ejecución edge o serverless donde el tamaño del bundle y los cold starts importan
- Tu equipo se siente cómodo con SQL y quieres transparencia en las consultas que realmente se están ejecutando
- El proyecto tiene requisitos de consulta complejos (reportes, análisis, agregaciones no estándar)
- Eres un desarrollador independiente o un equipo pequeño que quiere una sobrecarga de abstracción mínima
Elige Prisma si:
- Ejecutas una configuración tradicional de Node.js del lado del servidor con connection pooling
- Tu equipo tiene desarrolladores junior que se benefician del flujo guiado schema-first
- El proyecto es intensivo en CRUD y la complejidad relacional es moderada
- Quieres un ecosistema maduro con más herramientas de terceros, ejemplos y respuestas en Stack Overflow
Una cosa más que vale la pena mencionar: la documentación de Prisma es mejor. Sustancialmente. La documentación de Drizzle ha mejorado mucho en el último año, pero Prisma ha tenido más tiempo para construir tutoriales, guías y recursos comunitarios. Si estás aprendiendo sobre la marcha, esa brecha es real.
---
Notas de configuración práctica para Supabase específicamente
Sea cual sea tu elección, hay algunas cosas que se aplican universalmente al conectarse a Supabase.
- Usa la URI del connection pooler, no la conexión directa. Supabase proporciona un connection pooler de Supabase a través de PgBouncer. Para serverless, siempre usa esto. La
DATABASE_URLrecomendada de Prisma para serverless debe apuntar al endpoint del pooler en el puerto 6543. - Desactiva las prepared statements cuando uses PgBouncer. Prisma necesita
?pgbouncer=trueañadido a la URL. Drizzle necesitaprepare: falseconfigurado en la configuración de Postgres.js o node-postgres. Si lo omites, obtendrás errores crípticos en producción. - RLS es tu aliado pero tienes que configurar sesiones. Si quieres que las políticas RLS se apliquen a las consultas ORM, necesitarás establecer el rol de Postgres y la reclamación JWT a nivel de sesión. Este no es boilerplate que obtengas gratis.
- No luches contra las fortalezas de Supabase. Usa
supabase-jspara autenticación, realtime y almacenamiento. Usa tu ORM para consultas de datos complejas donde el filtrado del cliente de Supabase es insuficiente. Pueden coexistir en el mismo proyecto.
---
FAQ
¿Está Drizzle listo para producción en 2024?
Sí. Lo están usando en producción equipos de empresas que no son solo proyectos secundarios de fin de semana. La API ha sido lo suficientemente estable para trabajo serio desde finales de 2023. Aún diría que Prisma es más "probado en batalla" simplemente por antigüedad, pero Drizzle ya no es un riesgo.
¿Puedo usar ambos en el mismo proyecto?
Técnicamente sí. Hicimos exactamente esto brevemente (accidentalmente, no como estrategia). No lo hagas. La sobrecarga cognitiva no vale la pena, y tener dos sistemas de migración diferentes tocando la misma base de datos es pedirse un mal día. Elige uno.
¿Funciona Prisma con Supabase Edge Functions?
Prisma y Supabase Edge Functions (que se ejecutan en Deno) han tenido una relación complicada. El motor de Prisma no se ejecuta nativamente en Deno. Usar Prisma Accelerate o una configuración de pooling externa puede funcionar, pero añade complejidad. Drizzle no tiene estos problemas en entornos Deno.
¿Qué hay sobre type safety? ¿Son comparables?
Ambos generan tipos de TypeScript e integran bien con proyectos TypeScript. Los tipos de Drizzle se derivan de tus definiciones de esquema TypeScript. Los tipos de Prisma vienen del cliente generado. En mi experiencia, los tipos de relaciones anidadas de Prisma son ligeramente más ergonómicos por defecto, pero la inferencia de Drizzle ha alcanzado considerablemente.
¿Cuál es más rápido en tiempo de ejecución?
Drizzle tiene una ventaja de rendimiento genuina porque hay menos sobrecarga de tiempo de ejecución entre tu consulta y el protocolo Postgres. En benchmarks, la diferencia es medible. En la mayoría de aplicaciones reales es eclipsada por la latencia de red hacia tu base de datos. No elijas un ORM principalmente por velocidad de consulta bruta.
---
La Respuesta Real
Drizzle para proyectos Supabase en edge/serverless, o en cualquier lugar donde quieras estar cerca del metal. Prisma para entornos de equipo, apps pesadas en CRUD, y situaciones donde la velocidad de onboarding de desarrolladores importa.
Uso Drizzle más ahora que hace un año. Pero no me arrepiento de los años que pasé con Prisma. Me hizo mejor desarrollador, en parte por ser lo suficientemente opinado como para que tuviera que entender por qué estaba llegando a sus límites.
Ninguno hará o deshará tu proyecto. Lo hará tu diseño de schema. Lo harán tus decisiones de indexing. Elige el que se ajuste a la gente en tu equipo y comienza a construir.