Cada vez que tweeteo que estoy usando Postgres + Prisma para un producto nuevo, alguien me dice que debería usar X. Drizzle. Bun's SQLite. Turso. PlanetScale. SurrealDB. Y los argumentos siempre son válidos en algún plano teórico. Pero después de tres productos en VantLabs construidos sobre Postgres + Prisma, mi conclusión es que el aburrimiento es una feature.
El argumento "Prisma es lento"
Es cierto. Prisma tiene overhead vs un driver crudo de Postgres. En benchmarks artificiales, una query simple es 30-40% más lenta. En producción real, con queries que tocan disco, índices y red, esa diferencia se diluye al punto de ser irrelevante: 4ms vs 6ms para la mayoría de las queries que escribe un producto normal. Si tu producto es lo bastante caliente como para que esos 2ms importen, no estás escribiendo SaaS — estás escribiendo infraestructura, y Prisma no es para ti.
Para todo lo demás, Prisma me da el tipo de productividad que justifica esos 2ms diez mil veces al día: tipos generados automáticamente, migraciones declarativas, autocomplete que sabe qué columnas existen, y un schema único que es la fuente de verdad de la base de datos y del cliente TypeScript a la vez.
El argumento "Drizzle es mejor"
Drizzle es excelente. Tiene el modelo mental opuesto a Prisma: en lugar de un ORM con su propio query DSL, te da un query builder que se siente como SQL escrito en TypeScript. Para alguien que ya piensa en SQL, Drizzle es probablemente más rápido de escribir y más fácil de optimizar.
Pero para un solo founder, hay una ventaja invisible de Prisma que pocas comparaciones mencionan: el ecosistema. NextAuth tiene adapter oficial para Prisma. Inngest, Trigger.dev, y la mayoría de plataformas serverless tienen integraciones. Cuando algo se rompe a las 11pm de un viernes, hay 12 mil resultados en Stack Overflow y 30 issues abiertos discutiendo el caso exacto. Drizzle tiene todo eso pero más reciente, lo que en práctica significa menos respuestas en Google y más debugging solo.
El argumento "MongoDB es más simple"
Lo escucho cada año desde 2012 y cada año me parece más equivocado. MongoDB es más simple para escribir el primer modelo. Es más complejo para todo lo demás: relaciones, queries con joins, agregaciones, integridad referencial, migraciones, backup. Postgres con JSONB columns te da el 90% de la flexibilidad de Mongo cuando la necesitas (datos semi-estructurados), y el 100% del rigor relacional cuando la necesitas (todo lo demás).
En cualquier producto SaaS serio tienes una docena de entidades distintas con relaciones reales entre ellas: cuentas, sesiones, transacciones, recursos generados, audit logs, jobs en cola. Todo eso necesita consistencia transaccional. Postgres lo hace en una sola base con queries que un junior puede entender. Mongo te obliga a desnormalizar a mano y a sufrir cada vez que un usuario reporta que algo no le cuadra.
El argumento "deberías usar Edge functions con Turso/PlanetScale"
Turso es brillante para apps que necesitan latencia mínima a usuarios distribuidos globalmente. PlanetScale es brillante para escalas absurdas con sharding automático. Pero ReclamaAI sirve principalmente a usuarios colombianos. Las funciones serverless las corro en us-east, la base de datos en us-east, los usuarios están en Colombia (latencia base ~100ms a us-east). Ganar 30ms cambiando a edge no le mueve la aguja a nadie.
La regla que sigo: optimizo para tiempo de developer, no para latencia, hasta que la latencia se vuelva el cuello de botella real medido por usuarios reales. Hoy mi cuello de botella es el tiempo de Claude (3-8 segundos por documento), no la latencia de Postgres. Optimizar Postgres a costa de complejidad operativa sería arreglar el problema equivocado.
El verdadero costo de un stack trendy
Cada vez que adoptas un stack trendy, estás pagando un impuesto invisible: menos documentación, menos respuestas en foros, más bugs no descubiertos, menos integraciones maduras, y más probabilidad de que el proyecto se abandone o cambie radicalmente en 2 años. Para una empresa con equipo, ese impuesto puede valer la pena por una ventaja competitiva. Para un solo founder, es casi siempre una mala apuesta.
Postgres tiene 30 años. Prisma tiene 7 y es estable. La combinación es exactamente boring. No me hace ver listo en Twitter. Me deja construir productos.