MongoDB vs PostgreSQL

MongoDB y PostgreSQL son dos de las bases de datos más populares para aplicaciones web, APIs y bots. Las dos guardan y consultan tus datos, pero con modelos distintos. PostgreSQL organiza los datos en tablas con esquema fijo y las une con joins. MongoDB guarda documentos parecidos a JSON dentro de colecciones.

La elección correcta depende de la forma de tus datos y de cómo los lees, y las secciones siguientes las comparan punto por punto, con código. Si aún dudas entre familias de bases de datos, empieza por qué base de datos elegir.

¿Qué es cada una?#

PostgreSQL es una base de datos relacional de código abierto. Defines tablas con columnas tipadas y las consultas usan SQL. Las filas de tablas distintas se conectan mediante claves foráneas. Mira qué es PostgreSQL para lo básico.

MongoDB es una base de datos de documentos. Un registro es un documento BSON (una forma binaria de JSON) con objetos y arrays anidados, y los documentos viven en colecciones que no obligan a un esquema fijo. Las consultas usan la API propia de MongoDB y su pipeline de agregación, no SQL. Mira qué es MongoDB.

¿En qué se diferencian de un vistazo?#

¿Cómo cambia el modelo de datos tu diseño?#

Piensa en un pedido con un cliente y dos ítems. En MongoDB normalmente anidas todo en un documento:

{
  _id: "ord_1001",
  customer: { name: "Ana", email: "ana@example.com" },
  items: [
    { sku: "A-1", qty: 2, price: 19.9 },
    { sku: "B-7", qty: 1, price: 49.0 }
  ],
  status: "paid"
}

Una sola lectura devuelve el pedido completo. La documentación de MongoDB recomienda anidar los datos que se leen juntos. El costo es la duplicación: si el correo del cliente cambia, cada pedido que lo anidó conserva el valor viejo a menos que los actualices todos.

En PostgreSQL repartes los mismos datos en tablas relacionadas:

CREATE TABLE customers (
  id    bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  name  text NOT NULL,
  email text NOT NULL UNIQUE
);

CREATE TABLE orders (
  id          bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  customer_id bigint NOT NULL REFERENCES customers (id),
  status      text NOT NULL
);

CREATE TABLE order_items (
  order_id bigint NOT NULL REFERENCES orders (id),
  sku      text NOT NULL,
  qty      int  NOT NULL CHECK (qty > 0),
  price    numeric(10,2) NOT NULL
);

El correo vive en un solo lugar y la base rechaza un pedido de un cliente que no existe. Leer un pedido completo requiere un join, que es barato cuando las columnas de las claves foráneas tienen índice.

¿Cómo funcionan los joins y las relaciones?#

En PostgreSQL, los joins son el centro del lenguaje:

SELECT o.id, c.name, i.sku, i.qty
FROM orders o
JOIN customers c ON c.id = o.customer_id
JOIN order_items i ON i.order_id = o.id
WHERE o.status = 'paid';

MongoDB también puede hacer joins. La etapa $lookup hace un left outer join con una colección de la misma base de datos:

db.orders.aggregate([
  { $match: { status: "paid" } },
  { $lookup: {
      from: "customers",
      localField: "customerId",
      foreignField: "_id",
      as: "customer"
  } }
]);

Funciona, pero en un diseño de MongoDB es la excepción, no lo habitual. Si la mayoría de tus consultas necesita datos de tres o cuatro colecciones a la vez, estás peleando contra el modelo, y PostgreSQL te resultará más natural.

¿Cómo se comparan las transacciones?#

PostgreSQL gira en torno a las transacciones: cada sentencia se ejecuta dentro de una, y BEGIN ... COMMIT agrupa varias. Incluso ALTER TABLE puede ejecutarse dentro de una transacción.

En MongoDB, la escritura de un solo documento es atómica, con sus objetos y arrays anidados incluidos. También admite transacciones ACID con varios documentos en replica sets y en clústeres con sharding. Eso sí, tienen límites: una transacción debe terminar en 60 segundos por defecto (el parámetro transactionLifetimeLimitSeconds), y las transacciones largas presionan la caché de almacenamiento. La documentación indica mantenerlas cortas y modelar los datos para que la mayoría de las operaciones toque un solo documento.

Para movimientos de dinero, conteos de stock o cualquier caso en que dos registros deban cambiar juntos, PostgreSQL hace que el camino seguro sea el predeterminado.

¿Cómo manejan el JSON?#

PostgreSQL guarda JSON en una columna jsonb y puede indexarla con GIN:

CREATE TABLE events (id bigserial PRIMARY KEY, payload jsonb NOT NULL);
CREATE INDEX events_payload_gin ON events USING GIN (payload);

SELECT id FROM events WHERE payload @> '{"type": "signup"}';

Este modelo híbrido es un buen punto medio: columnas normales para los campos estables y una columna jsonb para la parte que varía. La documentación de PostgreSQL recomienda jsonb en lugar de json para la mayoría de las aplicaciones. Lo que pierdes son las herramientas que MongoDB creó para documentos, como su pipeline de agregación.

En MongoDB la misma consulta es nativa:

db.events.find({ type: "signup" });

¿Cómo escalan?#

En la mayoría de los proyectos el primer límite que aparece es un índice que falta o poca RAM, no el motor. Corrige eso primero.

Pasado ese punto, los enfoques difieren. PostgreSQL suele escalar primero en vertical (más RAM y CPU) y luego añade réplicas de lectura y particionado de tablas. MongoDB trae el sharding integrado: reparte una colección entre servidores según una clave de shard. Eso ayuda con conjuntos de datos muy grandes, pero la clave de shard es una decisión de diseño que conviene tomar pronto. Para entender los términos, mira colecciones, clústeres y replica sets.

¿Cuándo elegir cada una?#

Elige PostgreSQL si tus datos están muy relacionados (usuarios, pedidos, pagos), necesitas restricciones y joins, haces reportes con SQL o quieres una base de datos de propósito general como opción por defecto en un proyecto nuevo.

Elige MongoDB si los registros son autónomos y cambian de forma (catálogos con atributos distintos, contenido, registros de eventos, perfiles), los lees completos y tu equipo ya trabaja con objetos JSON en Node.js.

Si aún dudas, elige PostgreSQL para datos relacionales y añade jsonb donde necesites flexibilidad. Cambiar después es posible, pero cuesta trabajo real. Para comparar dentro de la familia SQL, mira PostgreSQL vs MySQL.

Cómo hacerlo en Square Cloud#

Square Cloud ofrece hospedaje de MongoDB y PostgreSQL desde el plan Standard, junto con MySQL y Redis. El plan Hobby no incluye hospedaje de bases de datos.

Creas la base en el panel, siempre en una versión reciente, y queda lista en segundos en el mismo datacenter que tus aplicaciones (unos 1 ms de latencia promedio), con TLS obligatorio. Ambas corren como nodo único (standalone), así que MongoDB no tiene replica set. PostgreSQL es el nativo, sin extensiones. Tú eliges el motor, conectas tu aplicación con la URL de conexión que te entrega el panel y controlas el resto.

Puedes tomar snapshots manuales cuando quieras, y todo plan que incluye bases de datos tiene también un snapshot automático diario. Puedes restaurar un snapshot en la misma base, en otra del mismo motor o en una base nueva. Ambos motores pueden convivir en el mismo plan, cada uno con al menos 1024 MB de la RAM del plan, así que puedes hacer la comparación de arriba con tus propios datos antes de decidirte.

Mira hospedaje de bases de datos, hospedaje de MongoDB y hospedaje de PostgreSQL.