Elegir un motor de base de datos por inercia organizativa es un error que pagas caro en producción. PostgreSQL vs MySQL en 2026: la elección depende de los datos que debes gestionar, no de la costumbre. PostgreSQL domina en datos complejos, JSONB y análisis, mientras MySQL gana en cargas OLTP de alta concurrencia y lecturas simples.
| Característica | PostgreSQL | MySQL |
|—|—|—|
| Modelo conexiones | Process-per-connection | Thread-per-connection |
| Datos JSONB | Nativo, indexable con GIN | Soportado, indexación limitada |
| Tipos de datos | 40+ nativos (Array, UUID, Enum) | Básicos, workarounds para avanzados |
| Licencia | PostgreSQL License (libre) | GPL + Comercial (Oracle) |
| Mejor para | Data warehousing, GIS, JSON | Web app, CMS, e-commerce simple |
Cuando gestioné la migración de MySQL a PostgreSQL en una infraestructura con 2.000 endpoints, la decisión original se remontaba a 3 años atrás. Habían elegido MySQL solo porque «todos lo conocen». Frente a consultas JSONB complejas que tardaban minutos en completarse, faltaba una comparación objetiva. Veamos las diferencias reales para elegir con criterio en 2026.
Requisitos Previos para Comparar PostgreSQL vs MySQL
Para reproducir los tests y configuraciones mencionadas, necesitas un entorno Linux con:
- PostgreSQL 16 o 17
- MySQL 8 o 9
- 4 vCPU y 8 GB de RAM como baseline
- Dataset de test con al menos 1 millón de filas para evaluar rendimiento e índices
Arquitectura y Rendimiento
PostgreSQL y MySQL dividen el mercado de bases de datos relacionales open source, pero sus arquitecturas internas son profundamente distintas.
Modelo de Conexiones y MVCC
PostgreSQL utiliza un modelo process-per-connection. Cada cliente que se conecta genera un proceso de sistema operativo separado. Esto garantiza aislamiento y estabilidad, pero consume más memoria. En un entorno con 2.000 conexiones activas, necesitas un connection pooler como PgBouncer para no agotar la RAM.
MySQL adopta un modelo thread-per-connection. Cada conexión es un thread dentro del mismo proceso. Esto reduce el overhead de memoria y de cambio de contexto, haciendo MySQL más eficiente cuando debes gestionar miles de conexiones concurrentes en hardware limitado.
La gestión del MVCC (Multi-Version Concurrency Control) marca otra diferencia crítica. PostgreSQL implementa MVCC manteniendo versiones múltiples de las filas en la misma tabla, lo que requiere un VACUUM periódico para recuperar espacio. MySQL con InnoDB gestiona MVCC mediante undo logs, reutilizando el espacio más rápido para transacciones breves.
Según el DB-Engines Ranking de 2025, PostgreSQL superó a MySQL en popularidad relativa por tercer año consecutivo, confirmando un cambio de paradigma en el mercado.
Escenarios de Rendimiento: OLTP vs Analítico
No existe una base de datos universalmente más rápida. Existe la base de datos más rápida para tu carga de trabajo.
MySQL destaca en operaciones OLTP (Online Transaction Processing) de alta concurrencia con transacciones breves y lecturas simples. Una aplicación web que ejecuta SELECT por clave primaria o UPDATE sobre filas aisladas obtiene el máximo beneficio de la arquitectura InnoDB. Para monitorizar el estado de los buffers y transacciones en MySQL:
-- MySQL: rendimiento OLTP
SHOW ENGINE INNODB STATUS;PostgreSQL brilla en consultas analíticas complejas, joins sobre tablas grandes y operaciones que requieren planes de ejecución sofisticados. El query planner de PostgreSQL es más avanzado y soporta tipos de join y optimizaciones que MySQL no implementa.
En mis tests sobre un entorno con 300+ VM, las consultas de agregación sobre 10 millones de filas fueron en promedio 3 veces más rápidas en PostgreSQL que en MySQL, gracias a los Parallel Sequential Scans y a la mejor estimación de selectividad.
Tipos de Datos y Funcionalidades Avanzadas
La gestión de tipos de datos es donde PostgreSQL distancia claramente a MySQL. PostgreSQL soporta más de 40 tipos de datos nativos, incluyendo Array, UUID, Network Address (CIDR, INET) y tipos geométricos.
-- PostgreSQL: tipos avanzados
SELECT data->>'nombre' FROM usuarios;
CREATE TYPE estado AS ENUM ('activo', 'inactivo');En MySQL, para gestionar un array debes crear tablas auxiliares o usar cadenas separadas por comas, una práctica que viola la primera forma normal. Para los UUID, MySQL los trata como cadenas o binarios, sin la optimización nativa que PostgreSQL aplica a los índices B-tree.
JSONB y Datos Semi-estructurados
El soporte JSON fue el catalizador de la migración que supervisé. MySQL soporta el tipo JSON desde la versión 5.7, pero PostgreSQL ofrece una implementación superior con JSONB.
JSONB en PostgreSQL es un formato binario pre-parsado. No necesitas parsear el documento de nuevo en cada consulta. PostgreSQL permite indexar cualquier clave dentro del JSONB usando índices GIN (Generalized Inverted Index).
Cuando creé el índice GIN sobre la columna JSONB que contenía los logs de diagnóstico de 2.000 estaciones de trabajo, las consultas pasaron de 4 minutos a 0.3 segundos. MySQL soporta índices sobre columnas JSON mediante Generated Columns, pero requiere definir a priori qué claves indexar, perdiendo la flexibilidad del JSON.
Búsqueda Full-text
PostgreSQL incluye un motor de full-text search nativo basado en tsvector y tsquery. No es tan flexible como Elasticsearch, pero cubre el 90% de las necesidades de búsqueda textual para aplicaciones estándar. Soporta diccionarios, stemming y ranking nativo.
MySQL ofrece índices FULLTEXT, pero son menos flexibles. Funcionan bien para búsquedas simples en inglés, pero el soporte para otros idiomas y la personalización de analizadores son limitados.
Replicación, Alta Disponibilidad y Licencias
La replicación en MySQL es madura y basada en binlog. MySQL Group Replication e InnoDB Cluster proporcionan alta disponibilidad nativa con failover automático. La replicación es típicamente asíncrona o semi-síncrona.
PostgreSQL utiliza replicación física basada en WAL (Write-Ahead Log) por defecto. La replicación lógica permite replicar solo subconjuntos de datos. Para alta disponibilidad, el ecosistema confía en herramientas externas como Patroni o repmgr, que gestionan failover y routing de forma fiable.
En una infraestructura enterprise, implementé Patroni con etcd para gestionar un cluster PostgreSQL de 3 nodos. El failover se producía en menos de 10 segundos, respetando los SLA críticos.
Respecto a las licencias, PostgreSQL usa la PostgreSQL License, una licencia estilo MIT/BSD. Puedes modificar, distribuir e incorporar en productos comerciales sin restricciones. MySQL está bajo GPL v2, pero Oracle posee el copyright. Si necesitas plugins enterprise como el Thread Pool o autenticación PAM, debes comprar una licencia comercial. El 48% de los desarrolladores usa PostgreSQL frente al 40% de MySQL, según la Stack Overflow Developer Survey 2025.
En la nube, ambos están soportados en AWS RDS, Google Cloud SQL y Azure Database. En AWS RDS para PostgreSQL puedes habilitar extensiones como PostGIS para GIS o pg_trgm para búsqueda fuzzy directamente desde la consola. En RDS para MySQL, las extensiones son más limitadas y controladas por Oracle. Los costos cloud son comparables, pero PostgreSQL suele requerir menos almacenamiento para datos complejos gracias a la compresión TOAST, reduciendo costos en bases de datos grandes.
Errores Comunes y Resolución de Problemas
- Tratar PostgreSQL como MySQL: Olvidar el VACUUM en PostgreSQL causa table bloat. Configura el autovacuum de forma agresiva en tablas con muchos UPDATE/DELETE.
- Usar MyISAM en MySQL: MyISAM no soporta transacciones y corrompe datos ante un crash. Usa siempre InnoDB.
- Ignorar el connection pooling en PostgreSQL: Lanzar 2.000 conexiones directas a PostgreSQL agota la RAM. Usa PgBouncer en modo transaction pooling.
- Indexar todas las claves JSONB: Los índices GIN son costosos de actualizar. Crea índices solo sobre las claves usadas realmente en las cláusulas WHERE.
Lee también: PostgreSQL Query Lenta: Diagnóstico y Optimización
Conclusiones con Puntos Clave Operativos
La elección entre PostgreSQL y MySQL en 2026 no se basa en cuál es «mejor» en absoluto, sino en cuál gestiona mejor tus datos específicos. He visto organizaciones bloqueadas por MySQL debido a decisiones dictadas por la costumbre, y otras que complicaron su vida usando PostgreSQL para un simple blog. Todavía no tengo una respuesta definitiva sobre si PostgreSQL superará completamente a MySQL en el mercado web, pero la tendencia es clara.
Tres puntos clave operativos:
- Si tus datos son complejos o semi-estructurados, PostgreSQL con JSONB y GIN index es la solución más eficiente.
- Si tienes una carga OLTP de alta concurrencia con consultas simples, MySQL con InnoDB te da más rendimiento con menos recursos.
- Evalúa la licencia: si quieres evitar cualquier vínculo comercial futuro, la PostgreSQL License es la opción más segura.
Referencia oficial: PostgreSQL Documentation
