Prisma + PostgreSQL para SaaS en 2026: el default razonable

El stack "PostgreSQL + Prisma" se ha consolidado como el default para SaaS indie en 2026. No porque sea la única opción (Drizzle, Kysely, raw SQL existen), sino porque la combinación de type-safety + migrations + DX es difícil de igualar.

Esta guía explica por qué este combo gana, qué patrones funcionan y qué errores evitar.

Qué te da Prisma + PostgreSQL

• Schema declarativo único: defines modelos en schema.prisma y de ahí salen tipos TS, cliente, migrations.
• Type-safety end-to-end: TypeScript sabe la forma de cada tabla, autocompletas queries.
• Migraciones automáticas: cambias el schema, lanzas migrate dev, lista.
• Prisma Studio: GUI para inspeccionar la DB sin instalar nada extra.

PostgreSQL aporta:

• Madurez y compatibilidad universal (cualquier provider lo soporta)
• JSON nativo (@db.JsonB) para campos flexibles
• Full-text search built-in
• Triggers, vistas, etc., si los necesitas

Schema básico SaaS

generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

model User {
  id        String   @id @default(cuid())
  email     String   @unique
  name      String?
  createdAt DateTime @default(now())
  posts     Post[]
}

model Post {
  id        String   @id @default(cuid())
  title     String
  content   String
  authorId  String
  author    User     @relation(fields: [authorId], references: [id])
  createdAt DateTime @default(now())

  @@index([authorId, createdAt])
}

Schema corto, todo lo necesario para arrancar.

Patrón cliente único

Mal:

// Cada vez que importas, instancias un PrismaClient nuevo
import { PrismaClient } from '@prisma/client';
const prisma = new PrismaClient();

En desarrollo, hot-reload abre nuevas conexiones cada vez. Acabas saturando la DB.

Bien:

// src/lib/db/client.ts
import { PrismaClient } from '@/generated/prisma/client';

declare global {
  var prisma: PrismaClient | undefined;
}

export const db = globalThis.prisma ?? new PrismaClient();

if (process.env.NODE_ENV !== 'production') {
  globalThis.prisma = db;
}

Y en cualquier parte: import { db } from '@/lib/db/client'.

Migrations en equipo

bunx prisma migrate dev --name add-billing-table

Crea archivo SQL, lo aplica a tu DB local, regenera el cliente. Lo commiteas con el código.

En producción:

bunx prisma migrate deploy

Aplica las migraciones pendientes. No genera SQL nuevo, solo aplica lo que ya está en prisma/migrations/.

Patrón query repetida

Si haces la misma query en 3+ sitios, sácala a un archivo:

// src/lib/db/queries/users.ts
import { db } from '@/lib/db/client';

export async function getUserById(id: string) {
  return db.user.findUnique({
    where: { id },
    include: { posts: { orderBy: { createdAt: 'desc' } } },
  });
}

Esto te da:

• Reusabilidad
• Un sitio donde cambiar la query si cambia el schema
• Tests más simples (mockeas el helper, no Prisma entero)

Prisma 7 y el adapter de PostgreSQL

Desde Prisma 7 (2025), el cliente requiere un adapter explícito:

import { PrismaPg } from '@prisma/adapter-pg';
import { PrismaClient } from '@/generated/prisma/client';

const adapter = new PrismaPg({ connectionString: process.env.DATABASE_URL! });
const prisma = new PrismaClient({ adapter });

Detalle pequeño pero crítico: si te lo saltas, los scripts standalone (bun script.ts) explotan con error de inicialización.

Errores comunes

1. Olvidar índices en columnas filtradas: si haces where: { userId }, mete índice. Sin él, en producción con 100k filas, la query tarda segundos.

2. findMany sin paginación: si la tabla puede crecer, paginar (take, skip, o cursor). Devolver 50k filas a un endpoint mata el server.

3. Hacer findUnique con campos no únicos: solo funciona con campos @unique. Para otros, findFirst.

4. Cargar relaciones que no usas: include: { posts: true } siempre que no las necesites es trabajo de DB que tiras a la basura.

Cuándo NO usar Prisma

• Necesitas SQL muy custom (CTEs complejos, window functions avanzadas) — usa raw queries para esos casos puntuales o pásate a Kysely
• Equipo backend que prefiere SQL puro — válido también
• Datasets enormes (>10TB) donde controlas cada query

Para el 95% de SaaS indie, Prisma es el default razonable.

Conclusión

Prisma + PostgreSQL en 2026 es el stack de DB con menor fricción para SaaS indie. Un schema, un cliente, type-safety, migraciones. Todo lo demás es ruido.

Si arrancas hoy, empieza aquí. Cuando crezcas y necesites algo más afilado, ya tendrás los datos para decidir.