PostgreSQL se ha convertido en la base de datos de referencia para la IA (y por qué deja atrás a MySQL)

Hace diez años, si preguntabas a un desarrollador qué motor de base de datos usar en un proyecto nuevo, la respuesta casi automática era MySQL. Rápido, conocido, con miles de proveedores de hosting baratos gracias a WordPress y a LAMP. Hoy esa respuesta ha cambiado. Entra en cualquier stack moderno de inteligencia artificial (RAG, agentes, búsqueda semántica) y lo que te vas a encontrar debajo, casi siempre, es PostgreSQL.

No es casualidad ni moda pasajera. Postgres lleva más de veinticinco años acumulando una característica que en 2020 nadie valoraba especialmente y que ahora resulta decisiva: la extensibilidad real a nivel de motor.

Qué hace distinto a PostgreSQL frente a MySQL

MySQL nació pensado para ser simple y veloz en lecturas web. PostgreSQL nació con otra filosofía, la de ser un sistema de bases de datos objeto-relacional que cumpliera el estándar SQL a rajatabla y que se pudiera ampliar sin tocar el núcleo. Esa decisión de diseño, tomada en Berkeley en los años ochenta, es la razón por la que hoy Postgres tiene algo que ningún otro motor relacional mainstream ofrece con la misma madurez: un sistema de extensiones que permite añadir tipos de datos, índices y funciones completamente nuevos.

Algunas diferencias que se notan en el día a día:

• Tipos de datos. Postgres soporta de forma nativa arrays, rangos, JSON binario (JSONB) indexable, geometría (PostGIS) y tipos personalizados. MySQL ha ido añadiendo JSON con el tiempo, pero sin la misma profundidad de indexación.
• Concurrencia (MVCC). Ambos usan control de concurrencia multiversión, pero la implementación de Postgres gestiona mejor las transacciones largas y las cargas mixtas de lectura y escritura simultáneas.
• Integridad y constraints. Postgres aplica claves foráneas, checks y triggers de forma estricta por defecto; en MySQL, según el motor de almacenamiento (MyISAM frente a InnoDB), el comportamiento históricamente ha sido más permisivo.
• Extensiones. pg_cron para tareas programadas, PostGIS para datos geoespaciales, TimescaleDB para series temporales, pg_stat_statements para monitorización de consultas. MySQL no tiene un mecanismo equivalente de extensión del núcleo.

La pieza que lo cambia todo: pgvector

Aquí está el motivo real por el que PostgreSQL ha pasado de ser «una alternativa sólida a MySQL» a convertirse en la base de datos por defecto de la industria de la IA generativa: la extensión pgvector.

Un modelo de lenguaje, o cualquier sistema de embeddings, transforma texto, imágenes o audio en vectores de cientos o miles de dimensiones. Para construir un sistema de Retrieval-Augmented Generation (RAG), esos chatbots que responden basándose en tus propios documentos, necesitas guardar esos vectores y poder buscar «los más parecidos a este otro vector» en milisegundos, sobre millones de filas.

Antes de pgvector, esto obligaba a montar una base de datos vectorial aparte (Pinecone, Weaviate, Qdrant) además de tu base de datos relacional de toda la vida. Ahora, con pgvector instalado, PostgreSQL guarda embeddings en una columna más, con índices HNSW o IVFFlat, y permite mezclar en la misma consulta SQL una búsqueda semántica con un filtro relacional normal:

SELECT id, titulo, contenido
FROM documentos
WHERE categoria = 'facturas'
ORDER BY embedding <-> '[0.021, -0.014, 0.087, ...]'
LIMIT 5;

Esa línea (buscar por categoría y por similitud semántica en la misma consulta, sin sincronizar dos sistemas distintos) es la razón por la que Supabase, Neon, Timescale y buena parte de las plataformas que dan de comer a las startups de IA han construido su propuesta entera encima de Postgres. No hace falta duplicar datos entre un almacén relacional y un almacén vectorial: es la misma fila, la misma transacción, el mismo backup.

PostgreSQL frente a otros motores

MongoDB sigue siendo una opción razonable cuando el esquema cambia constantemente y no necesitas transacciones complejas entre colecciones. SQL Server tiene sentido si ya vives dentro del mundo .NET y Azure. Pero ninguno de los dos ofrece la combinación que da Postgres: un motor relacional maduro, con SQL estándar de verdad, que además hace de base de datos vectorial sin instalar nada externo.

Por qué las empresas de IA están migrando hacia Postgres

Tres razones se repiten en casi todos los casos:

• Una sola fuente de verdad. Guardar los datos de negocio y los embeddings en el mismo motor evita el dolor de cabeza de mantener sincronizados dos sistemas, y dos copias de seguridad, y dos políticas de permisos.
• Coste. Una base de datos vectorial dedicada añade otra factura mensual. Si ya pagas por Postgres, sumar pgvector no cuesta nada extra de infraestructura.
• Herramientas maduras. Postgres lleva décadas de trabajo en replicación, backups, particionado y seguridad. Las bases de datos vectoriales «puras» todavía están poniéndose al día en ese terreno.

¿Significa esto que hay que abandonar MySQL?

No necesariamente. Si tu proyecto es un blog, una tienda online estándar o una aplicación con lecturas masivas y consultas simples, MySQL sigue siendo una opción perfectamente válida, barata de alojar y con soporte en cualquier hosting. El cambio real está en los proyectos nuevos que incorporan IA de alguna forma: ahí Postgres se ha convertido en la opción por defecto porque resuelve en un solo motor lo que antes exigía tres sistemas distintos.

Si vas a arrancar un proyecto desde cero en 2026 y existe la más mínima posibilidad de que acabe necesitando búsqueda semántica, recomendaciones o un chatbot sobre tus propios datos, empezar directamente en PostgreSQL con pgvector te ahorra una migración dolorosa dentro de un año.

Imagen: Pexels / panumas nikhomkhai