PostgreSQL, MongoDB o Supabase: cómo elegir la base de datos de tu proyecto

PostgreSQLMongoDBSupabasebases de datosbackend

“¿SQL o NoSQL?” es una de las preguntas que más genera debates inútiles en el mundo del desarrollo. La respuesta correcta es: depende del problema, no de tus preferencias personales o de lo que esté de moda.

Después de usar PostgreSQL, MongoDB, MySQL, Redis, Supabase y algunas otras en proyectos reales, aquí está mi visión honesta.

PostgreSQL: el caballo de batalla

PostgreSQL es mi opción por defecto para la mayoría de proyectos. Y hay buenas razones para ello.

Por qué lo elijo:

ACID garantizado: las transacciones son seguras. O todo se guarda o nada. Crítico cuando manejas dinero, pedidos, inventario.
Esquema rígido como ventaja: obliga a pensar bien la estructura de datos desde el principio. Eso parece una limitación, pero en proyectos que duran años, es lo que mantiene los datos coherentes.
SQL es universal: cualquier desarrollador que se incorpore al proyecto lo conoce.
Escalabilidad real: PostgreSQL aguanta cargas enormes con la configuración adecuada. Instagram y Shopify lo usan en producción.
JSON nativo: si necesitas algo de flexibilidad, tiene soporte JSON/JSONB excelente.

Cuándo es la elección correcta:

E-commerce, facturación, CRMs
Cualquier sistema donde la integridad de datos importa
Proyectos con esquema bien definido desde el inicio
Cuando el equipo tiene experiencia con SQL

-- Ejemplo: consulta que sería complicada en NoSQL
SELECT
  c.nombre,
  COUNT(p.id) AS total_pedidos,
  SUM(p.total) AS facturacion_total
FROM clientes c
LEFT JOIN pedidos p ON c.id = p.cliente_id
WHERE p.fecha >= NOW() - INTERVAL '30 days'
GROUP BY c.id
HAVING SUM(p.total) > 1000
ORDER BY facturacion_total DESC;

MongoDB: cuando los datos no tienen forma fija

MongoDB tiene mala fama en ciertos círculos, pero hay casos donde es genuinamente la mejor opción.

Por qué existe:

Esquema flexible: puedes guardar documentos con estructuras distintas en la misma colección. Útil cuando los datos evolucionan rápido o son intrínsecamente variables.
Documentos anidados: no necesitas JOINs para datos que siempre se leen juntos. Si un pedido siempre incluye sus líneas, tiene sentido guardarlos como un único documento.
Horizontal scaling nativo: se distribuye mejor entre múltiples servidores cuando el volumen es masivo.

Cuándo tiene sentido:

Catálogos de productos con atributos muy variables (una tienda de electrónica donde un TV tiene 20 especificaciones y una camiseta tiene 3)
Logs y eventos (donde el esquema puede variar y el volumen es alto)
Datos de sensores IoT
Prototipos rápidos donde el esquema no está claro

La trampa: muchos proyectos empiezan con MongoDB “para tener flexibilidad” y acaban con datos inconsistentes, duplicados y consultas que son mucho más complejas de lo necesario. La flexibilidad tiene un precio.

Supabase: PostgreSQL con superpoderes para startups

Supabase no es una base de datos diferente. Es PostgreSQL con una capa de servicios encima:

API REST y GraphQL generadas automáticamente
Autenticación integrada (email, OAuth, magic links)
Storage para archivos
Realtime (suscripciones en tiempo real a cambios en la DB)
Dashboard visual para gestionar datos

Por qué lo uso cada vez más: Para proyectos donde necesito moverme rápido, Supabase elimina semanas de trabajo. La autenticación, las APIs y el storage ya están listos. Solo me centro en la lógica de negocio.

// Con Supabase, esto es todo lo que necesitas para auth + datos
import { createClient } from '@supabase/supabase-js';

const supabase = createClient(url, key);

// Login con magic link
await supabase.auth.signInWithOtp({ email: 'usuario@empresa.com' });

// Consulta con Row Level Security automática
const { data, error } = await supabase
  .from('pedidos')
  .select('*, cliente:clientes(*)')
  .eq('estado', 'pendiente')
  .order('created_at', { ascending: false });

Cuándo lo elijo:

MVPs y startups que necesitan velocidad
Proyectos donde el equipo es pequeño y no hay un backend developer dedicado
Cuando necesito realtime sin complicaciones
Proyectos con presupuesto ajustado (el plan gratuito es generoso)

La limitación: el vendor lock-in. Aunque puedes exportar los datos (es PostgreSQL por debajo), la autenticación y las APIs de Supabase son específicas de la plataforma. Migrar es posible pero costoso.

Redis: no es una alternativa, es un complemento

Redis merece una mención aparte porque no compite con las anteriores: las complementa.

Redis es una base de datos en memoria, ultrarrápida. Lo uso para:

Caché: guardar el resultado de consultas costosas durante minutos u horas
Sesiones: gestionar sesiones de usuario de forma eficiente
Colas de trabajo: con Bull o BullMQ para procesar tareas en background
Rate limiting: controlar el número de peticiones por usuario/IP

En la mayoría de proyectos serios, acabas usando PostgreSQL + Redis. Cada uno para lo que sabe hacer mejor.

Mi árbol de decisión

¿Los datos tienen estructura fija y la integridad es crítica?
  └── Sí → PostgreSQL
  └── No → ¿Los datos son muy variables o el esquema no está claro?
              └── Sí → MongoDB
              └── No → ¿Necesitas velocidad de desarrollo y servicios integrados?
                          └── Sí → Supabase (PostgreSQL + servicios)
                          └── No → PostgreSQL

La mayoría de proyectos que construyo usan Supabase en las fases iniciales (velocidad + servicios listos) y migran a PostgreSQL puro con Prisma cuando la aplicación madura y necesitan más control.

¿Tienes dudas sobre qué base de datos usar en tu proyecto? Hablemos y lo vemos juntos.