La pregunta aparece en cada proyecto nuevo: ¿PostgreSQL o MySQL? Ambas son excelentes bases de datos relacionales de código abierto, pero tienen filosofías, fortalezas y casos de uso distintos. Esta guía te da los elementos para tomar la decisión correcta.
El contexto rápido
MySQL lleva desde 1995 y fue la base de datos de la web durante décadas. Es la “M” de LAMP y alimentó a Facebook, Twitter y Wikipedia en sus inicios. Hoy es propiedad de Oracle.
PostgreSQL (o simplemente “Postgres”) también lleva desde los 90 pero ha crecido explosivamente en popularidad en los últimos años. Es completamente comunitaria, sin empresa dueña. En la encuesta de Stack Overflow 2024, Postgres superó a MySQL como la base de datos más usada por desarrolladores profesionales.
Diferencias técnicas que importan
Tipos de datos
Postgres tiene un sistema de tipos mucho más rico:
-- Postgres: tipos nativos que MySQL no tiene o maneja diferente
CREATE TABLE productos (
id SERIAL PRIMARY KEY,
nombre TEXT NOT NULL,
precio NUMERIC(10, 2),
etiquetas TEXT[], -- Arrays nativos
metadata JSONB, -- JSON con índices
ubicacion POINT, -- Tipos geométricos
rango_stock INT4RANGE, -- Rangos
creado_en TIMESTAMPTZ -- Timestamp con zona horaria real
);
MySQL maneja JSON desde la versión 5.7, pero su implementación es menos potente y los índices sobre campos JSON son más limitados.
JSON y consultas semi-estructuradas
Si tu aplicación mezcla datos estructurados con semi-estructurados (como configuraciones por cliente, atributos variables de productos), Postgres con JSONB es imbatible:
-- Buscar productos cuyo metadata tenga color = "azul"
SELECT nombre FROM productos
WHERE metadata @> '{"color": "azul"}';
-- Índice GIN para acelerar estas consultas
CREATE INDEX idx_metadata ON productos USING GIN (metadata);
Transacciones y ACID
Ambas bases son ACID-compliant, pero Postgres aplica ACID de forma más estricta por defecto. Históricamente, MySQL con el motor MyISAM no era transaccional; con InnoDB (el default actual) sí lo es.
Postgres también soporta DDL transaccional: puedes hacer un ALTER TABLE dentro de una transacción y revertirlo con ROLLBACK. MySQL no.
-- Esto funciona en Postgres, no en MySQL
BEGIN;
ALTER TABLE usuarios ADD COLUMN telefono TEXT;
-- algo salió mal...
ROLLBACK; -- La columna no se agregó
Rendimiento en lectura masiva
MySQL históricamente fue más rápido en lecturas simples de alto volumen (SELECT por clave primaria, queries sencillos). Postgres ha cerrado esa brecha considerablemente, pero MySQL aún puede tener ventaja en workloads de lectura pura muy simples.
Para escrituras complejas, queries analíticos y JOINs pesados, Postgres suele ganar.
Full Text Search
Postgres tiene búsqueda de texto completo nativa bastante capaz:
-- Crear índice de texto
CREATE INDEX idx_fts ON articulos USING GIN (to_tsvector('spanish', titulo || ' ' || cuerpo));
-- Buscar
SELECT titulo FROM articulos
WHERE to_tsvector('spanish', titulo || ' ' || cuerpo) @@ plainto_tsquery('spanish', 'docker kubernetes');
Para proyectos pequeños y medianos puede evitar la necesidad de Elasticsearch.
Extensiones de Postgres que cambian el juego
Postgres tiene un sistema de extensiones que lo convierte en una navaja suiza:
- PostGIS: base de datos geoespacial completa. Uber, Lyft y Cabify corren sobre esto.
- pgvector: almacena y busca vectores de embeddings. Clave para aplicaciones de IA.
- TimescaleDB: convierte Postgres en una base de datos de series de tiempo.
- pg_cron: programa tareas directamente en la base de datos.
MySQL no tiene un ecosistema de extensiones comparable.
Cuándo elegir MySQL
- Tu equipo ya lo conoce y el proyecto es sencillo (CRUD clásico).
- Usas WordPress, Drupal, Magento u otro CMS/ecommerce que lo requiere.
- Necesitas máxima compatibilidad con hosting compartido legacy.
- Tu aplicación es de lectura masiva simple (un blog, un catálogo de productos básico).
Cuándo elegir PostgreSQL
- Datos complejos: JSON semi-estructurado, arrays, tipos geométricos.
- Necesitas transacciones robustas y DDL transaccional.
- Queries analíticos o reportes pesados.
- Geolocalización (con PostGIS).
- Aplicaciones con IA/ML que usan embeddings (con pgvector).
- Proyectos nuevos sin restricciones de legado.
La opinión directa
Para un proyecto nuevo en 2026, elige PostgreSQL por defecto. La mayoría de los servicios cloud modernos (Supabase, Neon, Railway, AWS RDS) lo soportan con igual o mayor facilidad que MySQL. Tiene más funcionalidades, una comunidad más activa en innovación y no tiene el overhead de una corporación (Oracle) sobre las decisiones del proyecto.
MySQL sigue siendo perfectamente válido, especialmente si tu equipo lo conoce bien o si tu stack lo requiere. No es una mala elección — simplemente Postgres es mejor para la mayoría de los casos de uso modernos.
Migrar de MySQL a Postgres
Si ya tienes MySQL y quieres migrar, herramientas como pgloader automatizan gran parte del proceso:
pgloader mysql://user:pass@localhost/mi_db \
postgresql://user:pass@localhost/mi_db
Aun así, revisa las diferencias de tipos de datos y los queries que usen funciones específicas de MySQL.
