¿Por qué montar otra base de datos si ya tienes PostgreSQL? La revolución del vector search nativo

Imagina que estás construyendo una aplicación moderna impulsada por Inteligencia Artificial —digamos, un sistema de recomendación inteligente o un motor de Búsqueda Aumentada por Generación (RAG). La receta clásica hasta hace poco era: guarda tus datos relacionales de usuarios, compras y catálogo en PostgreSQL… y luego añade una infraestructura extra como Pinecone, Qdrant o Milvus para gestionar los embeddings vectoriales. ¿El resultado? Dos sistemas que mantener, doble coste de infraestructura, problemas de sincronización en tiempo real e inconsistencias entre la base de datos principal y el almacén vectorial.

Aquí es donde entra el dilema de cualquier arquitecto de software: ¿realmente necesitamos añadir más piezas móviles a nuestra pila tecnológica sólo para hacer búsquedas por similitud semántica?

El problema de las bases de datos vectoriales dedicadas no es que funcionen mal, sino la sobreingeniería que imponen. Cuando consultas información que combina un filtro tradicional (por ejemplo: cliente_id = 42 y fecha > '2025-01-01') con una búsqueda semántica de documentos similares, la estrategia multi-base de datos se desmorona en complejidad. Tienes que hacer la consulta vectorial en un sitio, traerte las claves primarias y luego hacer un IN (...) gigantesco en Postgres, o viceversa. Un infierno para la latencia y la coherencia del sistema.

Ahí es donde el ecosistema de PostgreSQL ha dado un golpe sobre la mesa con la maduración de la extensión pgvector.

Para entender por qué esto cambia las reglas del juego, repasemos rápidamente qué es un embedding. Cuando pasas un texto o una imagen por un modelo de lenguaje, este convierte el significado en un vector: una lista de números en un espacio multidimensional (por ejemplo, 1.536 dimensiones). Buscar cosas similares no es más que calcular la distancia geométrica entre esos puntos en el espacio.

PostgreSQL no solo soporta almacenar estos arrays con el tipo de dato nativo vector, sino que con los índices HNSW (Hierarchical Navigable Small World) ha cerrado la brecha de rendimiento que antes solo tenían los motores especializados.

Un índice HNSW organiza los vectores en un grafo multicapa. Las capas superiores permiten dar «saltos largos» en el espacio multidimensional, mientras que las capas inferiores refinan la posición con precisión fina. Es literalmente como usar Google Maps: primero haces zoom a la ciudad, luego al barrio y finalmente encuentras el portal.

Gracias a esto, realizar consultas con operadores de distancia coseno (<=>), distancia euclídea (<->) o producto escalar (<#>) es cuestión de escasos milisegundos incluso sobre millones de filas.

-- Creamos una tabla con soporte para embeddings
CREATE TABLE articulos (
    id SERIAL PRIMARY KEY,
    titulo TEXT,
    contenido TEXT,
    embedding vector(1536)
);

-- Creamos un índice HNSW para acelerar la búsqueda por distancia coseno
CREATE INDEX ON articulos 
USING hnsw (embedding vector_cosine_ops);

-- Consulta híbrida: Búsqueda vectorial + Filtro relacional tradicional
SELECT titulo, 1 - (embedding <=> '[0.012, -0.043, ...]') AS similitud
FROM articulos
WHERE publicado = true
ORDER BY embedding <=> '[0.012, -0.043, ...]'
LIMIT 5;

¿El impacto real? Consistencia ACID completa y consultas híbridas en una sola sentencia SQL. Puedes unir (JOIN) tablas de clientes, verificar permisos de usuario y filtrar por fechas mientras realizas una búsqueda por similitud vectorial en la misma consulta, optimizada por el propio planificador de PostgreSQL. Sin sincronizaciones en segundo plano, sin pipelines de ETL frágiles y utilizando la misma infraestructura que ya sabes monitorear, escalar y respaldar.

Además, con mejoras recientes como el soporte de vectores de media precisión (halfvec) para reducir el uso de RAM a la mitad o la cuantización binaria, Postgres demuestra que no necesita ser sustituido, sino potenciado.

Obviamente, si tu caso de uso maneja más de 50 o 100 millones de vectores a escala hipermasiva con requisitos extremos de baja latencia pura, un motor especializado como Pinecone seguirá teniendo sentido. Pero para el 95% de los proyectos e integraciones RAG que construimos en el día a día, simplificar la arquitectura es la mejor decisión técnica que puedes tomar. 🤖

¿Has probado ya pgvector en tus entornos de producción o sigues manteniendo un cluster independiente para los vectores? ¡Te leo en los comentarios!