PostgreSQL vs MySQL en 2026: Cuál Elegir para Tu Proyecto (Guía Definitiva)

La pregunta PostgreSQL vs MySQL aparece en cada proyecto que empieza desde cero. No hay una respuesta única, pero hay una respuesta correcta para cada tipo de proyecto.

Llevo años usando los dos en producción y este artículo es la guía que me habría ahorrado elegir mal al principio.

El estado actual en 2026

PostgreSQL 17 es el estándar de facto para proyectos modernos. Supabase lo popularizó enormemente en el ecosistema JavaScript. Prisma, el ORM más usado con Node.js, recomienda PostgreSQL explícitamente.

MySQL 9 sigue siendo el más usado en términos absolutos (millones de apps en producción, WordPress, etc.). Oracle lo mantiene. MariaDB es la alternativa open source que muchos prefieren.

La tendencia es clara: proyectos nuevos eligen PostgreSQL. Proyectos legacy siguen con MySQL.

---

Diferencias técnicas que importan en el día a día

1. Tipos de datos: donde PostgreSQL gana claramente

-- PostgreSQL tiene tipos que MySQL no tiene nativamente:

-- Arrays
CREATE TABLE etiquetas_articulo (
  id SERIAL PRIMARY KEY,
  articulo_id INT,
  tags TEXT[]  -- Array nativo
);

INSERT INTO etiquetas_articulo (articulo_id, tags) 
VALUES (1, ARRAY['typescript', 'javascript', 'react']);

SELECT * FROM etiquetas_articulo 
WHERE 'typescript' = ANY(tags);  -- Búsqueda en array

-- JSON/JSONB (indexable, no solo almacenamiento)
CREATE TABLE configuraciones (
  id SERIAL PRIMARY KEY,
  usuario_id INT,
  datos JSONB
);

-- Índice GIN en columna JSONB
CREATE INDEX idx_config_datos ON configuraciones USING GIN(datos);

SELECT * FROM configuraciones 
WHERE datos @> '{"tema": "dark"}';  -- Query sobre JSON indexado

-- Enums nativos
CREATE TYPE estado_pedido AS ENUM ('pendiente', 'procesando', 'enviado', 'entregado');

CREATE TABLE pedidos (
  id SERIAL PRIMARY KEY,
  estado estado_pedido DEFAULT 'pendiente'
);

MySQL tiene JSON desde v5.7 y arrays se simulan con VARCHAR o tablas pivote. La diferencia es que PostgreSQL hace estos tipos indexables y eficientes.

2. Transacciones y ACID

PostgreSQL tiene cumplimiento ACID más estricto por diseño. Un ejemplo real donde importa:

-- PostgreSQL — DDL dentro de transacciones (MySQL no soporta esto)
BEGIN;
  ALTER TABLE usuarios ADD COLUMN premium BOOLEAN DEFAULT false;
  UPDATE usuarios SET premium = true WHERE plan = 'pro';
  -- Si algo falla, el ALTER TABLE también se revierte
ROLLBACK; -- o COMMIT

En MySQL, los comandos DDL (ALTER TABLE, CREATE INDEX, etc.) hacen commit implícito. No puedes revertirlos en una transacción.

3. Consultas avanzadas: CTEs, Window Functions, LATERAL

-- PostgreSQL — CTE recursivo para jerarquías (comentarios anidados, categorías)
WITH RECURSIVE comentarios_hilo AS (
  SELECT id, contenido, padre_id, 0 AS nivel
  FROM comentarios
  WHERE id = 1  -- Comentario raíz
  
  UNION ALL
  
  SELECT c.id, c.contenido, c.padre_id, h.nivel + 1
  FROM comentarios c
  INNER JOIN comentarios_hilo h ON c.padre_id = h.id
)
SELECT * FROM comentarios_hilo ORDER BY nivel;

-- Window Functions (disponibles en ambos, pero más potentes en PG)
SELECT 
  nombre,
  salario,
  AVG(salario) OVER (PARTITION BY departamento) AS media_dept,
  RANK() OVER (PARTITION BY departamento ORDER BY salario DESC) AS ranking
FROM empleados;

MySQL soporta CTEs y Window Functions desde v8.0, pero el soporte de PostgreSQL es más completo y maduro.

4. Full-Text Search

-- PostgreSQL FTS nativo — muy potente
SELECT 
  titulo,
  ts_rank(to_tsvector('spanish', contenido), query) AS relevancia
FROM articulos,
     to_tsquery('spanish', 'typescript & javascript') query
WHERE to_tsvector('spanish', contenido) @@ query
ORDER BY relevancia DESC;

-- Con índice GIN para FTS rápido
CREATE INDEX idx_articulos_fts ON articulos 
USING GIN(to_tsvector('spanish', contenido));

MySQL tiene FTS pero con capacidades más limitadas. Para un blog, un buscador interno, o una app con búsqueda de contenido, PostgreSQL es superior.

---

Herramientas y ecosistema

ORMs con Node.js

ORM	PostgreSQL	MySQL
Prisma	Soporte completo, recomendado	Soporte completo
Drizzle	Soporte nativo	Soporte nativo
TypeORM	Soporte completo	Soporte completo
Sequelize	Soporte completo	Soporte completo

Si usas Supabase vs Firebase, Supabase te da PostgreSQL gestionado con API REST y Realtime incluidos.

Servicios gestionados

PostgreSQL gestionado:

• Supabase: la opción más popular para proyectos JavaScript, tier gratuito generoso
• Neon: PostgreSQL serverless, paga por uso
• Railway: fácil de configurar, buena DX
• Render: opción sólida con tier gratuito
• AWS RDS: enterprise, costoso pero muy estable

MySQL gestionado:

• PlanetScale: MySQL serverless con branching (ahora de pago)
• AWS RDS MySQL: muy estable
• Google Cloud SQL: buen soporte
• Hosting compartido: la mayoría incluye MySQL, menos PostgreSQL

Si haces self-hosting con Coolify, ambas bases de datos están disponibles como contenedores con un click.

---

Cuándo MySQL sigue siendo la respuesta correcta

No todo es PostgreSQL. MySQL tiene ventajas reales en algunos escenarios:

1. Hosting compartido básico Si tu cliente tiene un hosting de 5€/mes, probablemente solo ofrece MySQL (cPanel, Plesk). No vale la pena la discusión.

2. Proyectos WordPress / PHP WordPress es MySQL. El ecosistema PHP está más orientado a MySQL. Si tu stack es PHP, no te compliques.

3. Equipo con experiencia profunda en MySQL Si tu equipo lleva 10 años con MySQL, conoce sus quirks, sabe optimizarlo y tiene procedimientos internos, no hay razón para cambiar por moda.

4. Replicación master-slave simple MySQL tiene una replicación más sencilla de configurar para casos de lectura escalada. PostgreSQL tiene streaming replication pero es más complejo.

---

Rendimiento: los benchmarks honestos

Los benchmarks de bases de datos son notoriamente difíciles de interpretar porque dependen del workload. Lo que sí puedo decir con experiencia:

Lecturas simples con índice: MySQL puede ser marginalmente más rápido (1-10%). En la práctica, irrelevante.

Escrituras concurrentes: PostgreSQL gana. El sistema MVCC de PostgreSQL maneja mejor la concurrencia sin bloqueos de tabla.

Queries complejas (JOINs múltiples, agregaciones, CTEs): PostgreSQL gana claramente. El planificador de queries es más sofisticado.

JSON / datos semi-estructurados: PostgreSQL con JSONB gana ampliamente.

Full-text search: PostgreSQL gana.

La conclusión es que para el 95% de las apps web, el rendimiento de la base de datos no es el cuello de botella — son los índices mal diseñados, las N+1 queries y la falta de caché.

---

Ejemplo real: migrar un proyecto de MySQL a PostgreSQL

Cuando migré un proyecto de MySQL a PostgreSQL, los cambios más comunes fueron:

-- MySQL                          -- PostgreSQL
AUTO_INCREMENT                 → SERIAL o GENERATED ALWAYS AS IDENTITY
TINYINT(1)                     → BOOLEAN
TEXT con collation              → TEXT (sin necesidad de especificar)
LIMIT x, y (offset, rows)      → LIMIT y OFFSET x
IFNULL(col, 'default')         → COALESCE(col, 'default')
GROUP BY sin agrupar todo       → Error (PG es más estricto, y correcto)
Backticks `nombre_tabla`       → Comillas dobles "nombre_tabla" (o nada)

El cambio más molesto: PostgreSQL es case-sensitive en identificadores sin comillas y los convierte a minúsculas. SELECT "UserName" FROM Users en MySQL funciona, en PostgreSQL necesitas comillas si usaste mayúsculas al crear la tabla.

---

Integración con IA y APIs modernas

Para proyectos que usan IA, PostgreSQL tiene una ventaja significativa: pgvector.

-- Instalar extensión pgvector
CREATE EXTENSION vector;

-- Tabla para embeddings de IA
CREATE TABLE documentos (
  id SERIAL PRIMARY KEY,
  contenido TEXT,
  embedding vector(1536)  -- Dimensiones de OpenAI text-embedding-3-small
);

-- Búsqueda por similitud coseno
SELECT contenido, 1 - (embedding <=> $1) AS similitud
FROM documentos
ORDER BY embedding <=> $1
LIMIT 10;

Si construyes un chatbot RAG o un sistema de búsqueda semántica como el que explico en crear un chatbot RAG con OpenAI, pgvector convierte PostgreSQL en una base de datos vectorial sin necesitar servicios externos como Pinecone o Weaviate.

---

Veredicto final

¿Proyecto nuevo en 2026?
├── ¿Usa WordPress o PHP legacy? → MySQL
├── ¿Solo tienes hosting compartido? → MySQL (o busca mejor hosting)
├── ¿Equipo con experiencia profunda en MySQL? → Quédate en MySQL
└── Cualquier otro caso → PostgreSQL

PostgreSQL es mejor en casi todo lo que importa en 2026: tipos de datos modernos, JSONB, arrays, FTS, ACID estricto, pgvector para IA, consultas complejas.

La única razón para elegir MySQL es una razón práctica (ecosistema existente, hosting, equipo) no técnica.

Si estás construyendo un SaaS nuevo, lee lo que nadie te cuenta sobre construir un SaaS en 2026 — la elección de base de datos es uno de los puntos que trato.