Si llevas unos cuantos años trasteando con bases de datos, sabrás que PostgreSQL es como ese martillo suizo que nunca te falla. ¿Tablas relacionales? Check. ¿JSON semiestructurado? Check. ¿Geolocalización con PostGIS? Check. Sin embargo, la revolución de la inteligencia artificial generativa nos ha planteado un problema que las bases de datos tradicionales no sabían gestionar bien: cómo almacenar, indexar y consultar embeddings vectoriales a gran escala sin tener que meter con calzador sistemas externos.
Hasta hace muy poco, cuando diseñábamos una arquitectura orientada a búsqueda semántica o RAG (Retrieval-Augmented Generation), nos veíamos obligados a bifurcar nuestros datos. Guardábamos los datos estructurados en nuestra base de datos relacional de confianza y enviábamos las representaciones numéricas de nuestros textos, imágenes o audios (los famosos vectores de alta dimensión) a una base de datos vectorial dedicada.
Esta fragmentación traía consigo el clásico dolor de cabeza de la sincronización de datos: transacciones distribuidas, latencias adicionales de red, problemas de consistencia eventual y la complejidad operativa de mantener dos infraestructuras completamente distintas. Para solucionarlo en el ecosistema Postgres solíamos recurrir a la extensión pgvector. Funcionaba genial para casos iniciales, pero a medida que los embeddings crecían en dimensiones y la multimodalidad (texto, visión y audio combinados) se volvía la norma, los índices vectoriales basados en memoria comenzaban a resentirse en rendimiento e integración con el planificador de consultas SQL.