¿Debe almacenar sus vectores de embeddings en una base de datos PostgreSQL mediante la extensión pgvector, o confiar esta tarea a una base de datos vectorial dedicada? Una guía técnica propone responder a la pregunta con mediciones de rendimiento en lugar de con argumentos de principio, comparando pgvector con Qdrant.
Dos arquitecturas, un mismo objetivo
pgvector es una extensión de código abierto para PostgreSQL, en versión 0.8.6, compatible con PostgreSQL 13 y versiones posteriores, según su repositorio oficial de GitHub. Añade a la base un tipo de columna dedicado a vectores, así como búsquedas exactas y aproximadas de vecinos más cercanos. Concretamente, un embedding, es decir, la representación numérica de un contenido en forma de vector, puede almacenarse en la misma tabla que los datos a los que se refiere, y consultarse con el lenguaje SQL habitual. Se ofrecen cinco funciones de distancia, incluidos el coseno y el producto escalar.
Una base de datos vectorial dedicada es, por el contrario, un servicio separado, con su propio motor de almacenamiento y diseñado en torno a la búsqueda vectorial. La guía menciona especialmente Pinecone, Qdrant, Weaviate, Milvus y ChromaDB. Esta elección arquitectónica implica desplegar, monitorizar y respaldar un sistema adicional, y mantenerlo sincronizado con la base que contiene los datos de referencia.
Mediciones locales, luego a gran escala
La guía propone una prueba reproducible en un ordenador portátil, con Docker, Python 3.10 o una versión posterior y aproximadamente 8 GB de RAM libre. El conjunto de datos es sintético: 100.000 vectores de 1536 dimensiones, es decir, el tamaño de un modelo de embeddings común, cargados en ambos sistemas con los mismos parámetros de índice HNSW. En tal hardware, las latencias se sitúan, según el autor, entre unos pocos milisegundos y unas pocas decenas de milisegundos, con fuertes variaciones según el procesador y la memoria disponibles. Este volumen sigue siendo demasiado modesto para extraer una conclusión de producción.
Para esta cuestión, la guía se basa en un estudio publicado por Tiger Data. Abarca 50 millones de embeddings Cohere de 768 dimensiones, probados en máquinas AWS r6id.4xlarge (16 vCPU, 128 GB de RAM), con una versión modificada de la herramienta ANN-Benchmarks. La guía subraya un punto importante: la prueba se realizó con pgvector asociado a pgvectorscale, una extensión de Timescale que añade otro tipo de índice, StreamingDiskANN, y no con pgvector solo.
Según estos resultados, con un recall del 99 %, PostgreSQL con pgvectorscale alcanza 471,57 consultas por segundo, frente a 41,47 de Qdrant. La latencia mediana es casi idéntica, con 31,07 ms frente a 30,75 ms. Qdrant se distingue, en cambio, en las latencias extremas: su p99 es de 38,71 ms, frente a 74,60 ms, y su índice se construyó en 3,3 horas, frente a 11,1 horas. Para la guía, ambos sistemas se mantienen por debajo de los 100 ms en todos los percentiles medidos.
Qué elección según la carga de trabajo
La guía estima que pgvector es adecuado para volúmenes de hasta aproximadamente 5 a 10 millones de vectores, con una concurrencia de consultas moderada y cuando un equipo ya domina PostgreSQL. También destaca la coherencia transaccional entre datos relacionales y vectores, que permite actualizar un documento y su vector en una misma transacción.
Por el contrario, una base dedicada se justifica, según el artículo, para volúmenes de varios cientos de millones a varios miles de millones de vectores, o para una restricción estricta de latencia extrema en búsquedas filtradas muy solicitadas, ámbito donde Qdrant presenta la ventaja medida. Se cita a Milvus por la indexación acelerada por GPU, y a Pinecone por ser un servicio completamente gestionado, sin administración interna que realizar.
