PostgreSQL con pgvector frente a las bases de datos vectoriales dedicadas

Durante la fiebre generativa de 2023 y 2024 el sector asumió que los motores relacionales no aguantarían la búsqueda semántica, y que cada aplicación con embeddings necesitaba su propio motor vectorial. Un análisis de arquitectura defiende ahora lo contrario con un caso concreto: indexar 50.000 documentos de soporte en un servicio dedicado de 300 dólares al mes, cuando PostgreSQL con pgvector resuelve esa misma consulta en 8 milisegundos y sin coste añadido. Las cifras son del autor, no de una medición independiente.

Cuatro fallos que no aparecen en la factura

El argumento no va de precio, va de acoplamiento. Meter un motor vectorial externo crea una segunda fuente de verdad y, con ella, el problema de la doble escritura: si la transacción en PostgreSQL confirma pero la llamada a la API del proveedor expira, el estado se desincroniza. Arreglarlo obliga a montar colas de eventos, patrón outbox o canalizaciones CDC, con cientos de líneas de pegamento y más puntos de fallo.

Lo segundo que se pierde es la atomicidad. En PostgreSQL, un bloque BEGIN ... COMMIT garantiza que borrar un documento y borrar su embedding ocurren en la misma operación. Con un motor externo, la consistencia eventual es el mejor escenario posible. A eso se suma la latencia: una consulta RAG real casi nunca busca vectores en crudo, filtra por metadatos relacionales —versión del manual, inquilino, fecha—, y en una arquitectura partida eso son tres viajes de red que añaden entre 50 y 150 milisegundos. Con pgvector todo eso se resuelve en una sola consulta dentro del mismo proceso.

El cuarto punto es la seguridad. En aplicaciones multiinquilino, Row Level Security dentro del kernel impide que un usuario recupere embeddings de otra organización sin depender de que la capa de aplicación replique bien la lógica de autorización en tres sitios distintos.

HNSW e IVFFlat

Operar pgvector en producción exige entender cómo indexa. La extensión soporta los dos algoritmos dominantes del sector. IVFFlat divide el espacio de alta dimensión en K clusters mediante k-means y busca en las listas invertidas correspondientes, con el compromiso habitual entre recall y velocidad. Para HNSW, la guía de referencia es la de AWS sobre optimización de índices HNSW en PostgreSQL.

La tabla de ejemplo es una columna VECTOR(1536), la dimensión típica de los embeddings de OpenAI o Vertex AI, junto al texto y los metadatos relacionales que después se filtran.

Lo que queda sin desarrollar es la otra mitad del argumento: en qué punto compensa de verdad un motor dedicado. Los proveedores prometen escalado a miles de millones de vectores, y el texto no entra en cuándo ese escenario se vuelve real. Sin esa parte, la decisión se plantea como una elección de arquitectura y no como una línea más del recibo de la nube, que es exactamente como debería plantearse.