Postgres vs MongoDB en 2025: cuándo usar cada uno (con benchmarks reales)

La pregunta "Postgres o MongoDB" parece eterna, pero el contexto cambió mucho en los últimos años. PostgreSQL 17 maneja JSON con jsonb casi tan bien como un sistema documental nativo, soporta búsqueda vectorial vía pgvector, escala horizontalmente con Citus y tiene replicación lógica madura. MongoDB 8 ya tiene transacciones ACID multidocumento, time-series collections y una arquitectura de búsqueda vectorial integrada (Atlas Vector Search).

En 2025 la elección rara vez es de capacidades. Es de patrones de acceso, costo total y conocimiento del equipo. En este artículo comparamos los dos a partir de benchmarks que corrimos en cargas reales y damos un marco para decidir sin caer en moda.

El estado del arte en 2025

PostgreSQL 17 (lo relevante)

• JSONB con índices GIN avanzados y operadores que llegan al nivel de un sistema documental para la mayoría de los queries.
• pgvector 0.7 con índices HNSW y IVFFlat para búsqueda semántica integrada con datos relacionales.
• Replicación lógica bidireccional y soporte robusto para multi-tenant.
• Particionamiento declarativo que ya no requiere extensiones externas para volumen alto.
• Ecosistema maduro de extensiones: PostGIS, TimescaleDB, Citus.

MongoDB 8 (lo relevante)

• Transacciones ACID multidocumento estables, ya sin las advertencias que aparecían en versiones anteriores.
• Time-series collections con compresión y agregación eficiente para datos IoT y telemetría.
• Atlas Vector Search integrado con HNSW.
• Sharding mejorado con balanceo automático más predecible.
• Modelo flexible que sigue siendo difícil de igualar cuando los documentos son verdaderamente heterogéneos.

Benchmarks que corrimos

Probamos cuatro cargas representativas en instancias equivalentes (8 vCPU, 32 GB RAM, NVMe local, en AWS us-east-1). Postgres 17 corriendo en RDS y MongoDB 8 en Atlas M40. Los números son promedio de tres corridas.

Carga 1: e-commerce típico (relacional con JSON ocasional)

Modelo: pedidos, ítems, clientes, productos. 50 millones de pedidos.

• Postgres: 4,200 lecturas/seg, 1,800 escrituras/seg, JOIN de 4 tablas en p95 de 12 ms.
• MongoDB: 3,100 lecturas/seg, 2,400 escrituras/seg, agregación equivalente con $lookup en p95 de 38 ms.

Postgres gana claramente cuando hay relaciones que se consultan juntas.

Carga 2: catálogo heterogéneo (documentos con esquemas variables)

Modelo: productos con atributos muy distintos por categoría. 10 millones de documentos.

• Postgres: lecturas con filtros dentro de JSONB en p95 de 45 ms con índices GIN bien afinados.
• MongoDB: lecturas equivalentes en p95 de 22 ms.

MongoDB gana cuando el esquema es genuinamente heterogéneo y los queries varían mucho.

Carga 3: time-series (IoT con 200 dispositivos enviando datos cada segundo)

• Postgres con TimescaleDB: ingesta de 220K puntos/seg, agregaciones por hora en 80 ms.
• MongoDB time-series collections: 280K puntos/seg, agregaciones por hora en 65 ms.

MongoDB lleva ligera ventaja en ingesta y latencia. Para cargas pesadas de IoT, vale la pena evaluar.

Carga 4: búsqueda semántica con embeddings

10 millones de embeddings de 768 dimensiones, queries top-K = 20.

• Postgres con pgvector (HNSW): p95 de 28 ms, recall 97%.
• MongoDB Atlas Vector Search: p95 de 22 ms, recall 96%.

Empate técnico. La diferencia real está en si quieres que los vectores convivan con datos relacionales (ventaja Postgres) o documentales (ventaja MongoDB).

Cuándo usar Postgres

Recomendamos Postgres cuando:

• El modelo es predominantemente relacional. Si tienes facturas con líneas, clientes con direcciones, pedidos con ítems, Postgres es la opción natural.
• Necesitas ACID estricto sin paréntesis. Aunque Mongo ya lo hace, Postgres lo hace con menos sorpresas.
• Quieres minimizar dependencia de un solo proveedor. Postgres corre en cualquier nube, on-premise y en proveedores managed económicos (Supabase, Neon, RDS, Cloud SQL).
• Tu equipo viene de SQL. El conocimiento idiomático de SQL paga dividendos por años.
• Requieres extensiones especializadas: PostGIS, TimescaleDB, pgvector, pg_partman.

Cuándo usar MongoDB

Recomendamos MongoDB cuando:

• Los documentos son verdaderamente heterogéneos y el esquema cambia rápido.
• Necesitas escalar horizontalmente y prefieres no pelear con sharding manual.
• Operas mucha telemetría o IoT y vas a aprovechar time-series collections.
• Tu equipo ya tiene experiencia profunda en el ecosistema y herramientas Mongo.
• Estás en Atlas y quieres aprovechar Search, Vector Search y Charts integrados.

El factor que casi nadie considera: costo operacional

Los costos de licencia se publicitan, pero los costos operacionales reales rara vez se discuten. Algunos puntos:

• Postgres en managed services suele ser entre 30% y 50% más barato a igualdad de recursos. Atlas M-series escala bien, pero no es barato.
• Backup y restore: Postgres tiene pg_basebackup y herramientas como WAL-G muy probadas. Mongo tiene mejor experiencia con Atlas, pero fuera de Atlas la operación es más compleja.
• Migración entre proveedores: Postgres es portable. Si mueves datos de Atlas a otro Mongo managed, hay fricción.

Para una pyme o scale-up mexicana con presupuesto controlado, el costo operacional de Postgres suele ser determinante.

Lo que NO es razón para elegir

Tres razones que escuchamos seguido y que no deberían pesar:

• "MongoDB es para microservicios." No. La elección de DB no se decide por arquitectura de servicios.
• "Postgres es lento para escalar." Postgres escala bien hasta volúmenes altísimos. Pocas empresas mexicanas llegan al punto donde Postgres se cae por escala.
• "NoSQL es más moderno." NoSQL tiene 20 años. La modernidad no es métrica útil.

Estrategia híbrida (cuando aplica)

Hay casos donde combinar tiene sentido. Ejemplo común: Postgres como base transaccional (clientes, pedidos, finanzas) y MongoDB como almacén de eventos o catálogo flexible. La clave es que cada motor haga lo que mejor hace y que los puntos de integración estén bien definidos.

Otra combinación que vemos en empresas con AI: Postgres para datos operacionales y pgvector para embeddings, sin agregar otra base. La simplicidad gana.

Recomendación general para 2025

Si estás arrancando un proyecto nuevo en una empresa mexicana mediana, nuestra recomendación por defecto es PostgreSQL. Cubre el 85% de casos de uso, su costo operacional es menor, el talento es más fácil de encontrar y la portabilidad entre proveedores te protege a futuro.

MongoDB sigue siendo excelente para casos donde su modelo brilla. Pero la elección debe ser deliberada, no por inercia.

Cierre

La buena base de datos no es la más popular ni la más nueva. Es la que tu equipo puede operar bien, que se ajusta a tus patrones de acceso reales y que no te ata a un solo proveedor más de lo necesario. Tomarse 4 horas para correr benchmarks en tus propios datos antes de decidir paga durante años.

---

En ALCA damos segundas opiniones independientes sobre arquitectura de datos y elegimos motores con base en datos, no en moda. ¿Quieres una segunda opinión sobre tu elección de DB? Conversemos. Agenda una llamada de 30 minutos.