MongoDB vs PostgreSQL en 2024: cómo elegir sin arrepentirte en 6 meses

He migrado dos proyectos de MongoDB a PostgreSQL y uno de PostgreSQL a MongoDB. Cada migración costó semanas. Si hubiera tomado la decisión correcta desde el inicio, no habrían sido necesarias. Aquí está el framework de decisión que uso ahora.

El error más común: elegir por popularidad

“Todos usan Mongo para apps Node.js” y “PostgreSQL es el estándar de la industria” son argumentos que no te ayudan a elegir. La decisión correcta depende de una sola pregunta central:

¿Cómo se accede a tus datos mayoritariamente: de forma documental (lees el objeto completo) o relacional (combinas entidades distintas)?

Cuándo MongoDB gana claramente

1. Tus documentos son la unidad natural de tu dominio

Un perfil de usuario con sus preferencias, historial de configuración y metadatos es un documento natural. Siempre lo lees completo, raramente lo combinas con otras entidades:

// Esto es un documento, no una tabla
{
  _id: "usr_123",
  name: "Daniel Palacio",
  preferences: {
    theme: "dark",
    notifications: { email: true, push: false },
    language: "es"
  },
  recentActivity: [
    { type: "login", at: ISODate("2024-10-28"), ip: "192.168.1.1" },
    { type: "purchase", at: ISODate("2024-10-27"), amount: 49.99 }
  ]
}

En PostgreSQL, modelar esto requiere 3-4 tablas y JOINs para cada lectura. En MongoDB, es una operación de lectura.

2. Tu schema evoluciona constantemente

En startups early-stage donde el modelo de datos cambia cada sprint, las migraciones de PostgreSQL se vuelven un obstáculo. MongoDB te permite agregar campos sin migrations. Cuando el modelo se estabilice, puedes migrar.

3. Escrituras masivas con estructura variable

Logs, eventos de telemetría, datos de IoT. Cada evento puede tener campos distintos. MongoDB maneja esto nativamente.

Cuándo PostgreSQL gana claramente

1. Tus datos son inherentemente relacionales

Pedidos → Productos → Categorías → Proveedores. Esta red de relaciones se modela de forma natural y eficiente con JOINs, no desnormalizando todo en documentos gigantes:

SELECT o.id, u.name, SUM(oi.quantity * p.price) as total
FROM orders o
JOIN users u ON u.id = o.user_id
JOIN order_items oi ON oi.order_id = o.id
JOIN products p ON p.id = oi.product_id
WHERE o.created_at > NOW() - INTERVAL '30 days'
GROUP BY o.id, u.name;

En MongoDB, esta query requiere múltiples $lookup encadenados que son considerablemente más lentos y verbosos.

2. Necesitas ACID a nivel de múltiples documentos

¿Transferences bancarias, inventario, cualquier cosa donde “si falla una parte, falla todo”? PostgreSQL. Las transacciones multi-documento de MongoDB existen pero son significativamente más costosas en rendimiento.

3. Queries ad-hoc y análisis

Si tu equipo de datos va a hacer consultas que no conoces de antemano, el modelo relacional y SQL son imbatibles. El aggregation pipeline de MongoDB es poderoso, pero SQL sigue siendo la lingua franca del análisis.

La zona gris: PostgreSQL + JSONB

Lo que mucha gente no sabe: PostgreSQL tiene soporte nativo de JSON con indexación:

-- Columna JSONB indexable
ALTER TABLE users ADD COLUMN preferences JSONB;

-- Índice GIN para búsquedas dentro del JSON
CREATE INDEX idx_users_prefs ON users USING GIN (preferences);

-- Query sobre datos JSON
SELECT * FROM users
WHERE preferences @> '{"notifications": {"email": true}}';

Esto te da lo mejor de ambos mundos para casos mixtos: estructura relacional donde la necesitas, flexibilidad documental donde la necesitas.

Mi regla de decisión actual

¿Datos relacionales complejos? → PostgreSQL
¿Documentos auto-contenidos + schema cambiante? → MongoDB
¿Mixto o no estás seguro? → PostgreSQL + JSONB

La mayoría de aplicaciones web son más relacionales de lo que creen al inicio. El document store es seductor al principio y doloroso cuando necesitas agregar datos que no planificaste.

Elige aburrido. PostgreSQL es aburrido. Los proyectos aburridos llegan a producción.