Para un SaaS que va a escalar, la opción por defecto correcta es PostgreSQL. Cubre alrededor del 90 % de lo que necesita un producto web o móvil: datos transaccionales, relaciones entre entidades, búsqueda, JSON, colas ligeras e incluso parte de la carga vectorial para la IA. La verdadera pregunta casi nunca es "relacional o NoSQL": es "tengo una razón concreta para NO usar Postgres". La mayoría de las veces, no.
PostgreSQL por defecto: por qué funciona 9 de cada 10 veces
Un SaaS maneja datos estructurados y relacionados entre sí: usuarios que pertenecen a organizaciones, suscripciones vinculadas a facturas, proyectos vinculados a tareas. Es exactamente para lo que se crearon las bases relacionales. Postgres añade sobre esa base superpoderes que evitan apilar herramientas: columnas JSONB para lo semiestructurado, búsqueda de texto completo integrada, la extensión pgvector para los embeddings de IA y restricciones que garantizan la integridad de tus datos.
- Transacciones ACID: tus pagos y datos críticos se mantienen coherentes, incluso tras una caída.
- Un solo sistema que operar, respaldar y monitorizar en lugar de tres: menos costes, menos caídas.
- Ecosistema maduro: Prisma, migraciones, replicación, hosting gestionado en todas partes (Cloud Run, Neon, Supabase, RDS).
- JSONB cuando necesitas flexibilidad, sin renunciar a lo relacional para el resto.
Relacional vs NoSQL: cuándo salir de Postgres
NoSQL (MongoDB, DynamoDB, Firestore) no es "más moderno", responde a otras restricciones. Solo ganas si tu caso de uso encaja de verdad: volumen masivo con muchísima escritura, un esquema realmente impredecible o necesidad de una distribución geográfica extrema. Para un SaaS B2B típico en fase de lanzamiento y crecimiento, esas restricciones aún no existen, y adoptar NoSQL demasiado pronto te hace pagar en complejidad algo que nunca usarás.
Elegir NoSQL porque "escala" cuando tienes 200 usuarios es optimizar un problema que no tienes, a costa de los que ya tienes.
Índices, migraciones, escalado: tres reflejos desde la V1
Una base bien elegida no basta: son tres hábitos los que deciden si tu SaaS aguanta con 10 000 usuarios. Primero, los índices: una consulta que escanea una tabla entera es rápida con 100 filas y catastrófica con 1 millón. Indexa las columnas que filtras y unes con frecuencia, y mide con EXPLAIN. Luego, las migraciones: cada cambio de esquema debe estar versionado y ser reproducible (Prisma Migrate), nunca aplicado a mano en producción. Por último, el escalado: primero vertical (más CPU/RAM), añade réplicas de lectura y piensa en el sharding solo muy tarde; la mayoría de los SaaS nunca llegan ahí.
- Índices: apunta a las columnas de las cláusulas WHERE, JOIN y ORDER BY; un mal índice cuesta escritura, uno que falta mata la lectura.
- Migraciones: versionadas, probadas, reversibles; la base evoluciona con el producto sin downtime.
- Escalado: primero vertical, luego réplicas de lectura; Postgres soporta millones de filas mucho antes de que aparezca el sharding.
La decisión correcta para una V1
Elegir PostgreSQL desde el primer día, modelar con limpieza, poner los índices adecuados y versionar las migraciones: eso es lo que te evita una reescritura al mes 12. Es exactamente la base que montamos en nuestras V1 entregadas en 7 días por 15 000 € —Next.js, NestJS, Prisma y Postgres—, una base que te acompaña desde tu primer cliente hasta el salto de escala, sin deuda técnica oculta.