pgvector frente a Qdrant: benchmark con 100 000 vectores de 1536 dimensiones

El debate sobre «Postgres con extensión o una base de datos vectorial aparte» suele librarse a base de afirmaciones tajantes. Machine Learning Mastery propone sustituirlas por una medición: pgvector y Qdrant se ejecutan en Docker en la misma máquina, reciben los mismos 100 000 vectores de 1536 dimensiones (como los de OpenAI text-embedding-3-small) y la misma configuración del índice HNSW. El resultado se lee en cuatro métricas: la latencia mediana p50, las colas p95 y p99, y el número de consultas por segundo.

Un debate sin cifras

La historia típica es esta. Un martes, un equipo añade pgvector a un Postgres que ya está en producción. Los embeddings conviven con los datos relacionales y una sola consulta filtra y busca similares a la vez. Seis meses después llega un correo de un proveedor: toca migrar a una base de datos vectorial «de verdad» antes de chocar con el techo. El correo no incluye ningún benchmark, solo seguridad.

pgvector es una extensión de código abierto para Postgres; su versión actual es la 0.8.6 y admite Postgres 13 y posteriores. Añade un tipo nativo vector y permite la búsqueda exacta y aproximada de vecinos más cercanos. El vector se almacena en la misma tabla (y, si se quiere, en la misma fila) que el registro al que describe, y se consulta con SQL corriente. No hay un servicio aparte, no hay que sincronizar una segunda fuente de datos y tampoco existe un salto de red entre la parte relacional y la vectorial. La extensión admite vectores de precisión simple y media, binarios y dispersos, así como cinco funciones de distancia: L2, producto escalar, coseno, L1 y Hamming.

Las cinco bases dedicadas con las que se compara Postgres

Una base de datos vectorial dedicada es un servicio independiente, con su propio proceso y almacenamiento, diseñado desde cero para la búsqueda vectorial. El precio de esta opción está claro: hay que desplegar un sistema nuevo, monitorizarlo, hacer copias de seguridad y sincronizarlo con la fuente de verdad. El autor repasa las cinco opciones más populares:

• Pinecone: base de datos en la nube totalmente gestionada, sin configuración, pensada para escala corporativa con un mínimo de operación.
• Qdrant: base de datos de alto rendimiento escrita en Rust, fuerte en consultas rápidas con filtrado complejo por payload JSON.
• Weaviate: sistema de código abierto orientado a la IA, con vectorización integrada y búsqueda híbrida con BM25.
• Milvus: base de datos distribuida con aceleración por GPU para cargas masivas de miles de millones de vectores.
• ChromaDB: base de datos ligera y embebida para prototipado local y desarrollo en Python.

Para la comparación práctica se eligió Qdrant: es la que cuenta con el benchmark público más detallado y metodológicamente transparente frente a pgvector, y el artículo se apoya en él.

Cómo se diseña una medición justa

Postgres 17 con la extensión se levanta desde la imagen pgvector/pgvector:pg17, y Qdrant con un único comando docker run en los puertos 6333 y 6334. En ambos sistemas la dimensión es 1536 y la métrica, coseno. El dataset es sintético: 100 000 vectores de una distribución normal con seed=42 fijo, normalizados a longitud unitaria, como hacen los modelos de embeddings reales. En Qdrant los datos se cargan en lotes de 1000 puntos; en Postgres, mediante el adaptador pgvector-python.

La decisión clave es que los índices sean idénticos. En pgvector se crea un HNSW con m=16 y ef_construction=64 (sus valores por defecto), y en Qdrant se fijan los mismos valores mediante HnswConfigDiff. El autor señala expresamente que comparar con parámetros de índice distintos produce dos resultados no comparables. Del lado de las consultas, hnsw.ef_search también es 64 y el límite de resultados, 10.

Las consultas se hacen con 200 vectores nuevos que no están en el conjunto cargado. De lo contrario, un vector que ya estuviera en el índice se encontraría a sí mismo a distancia cero y la medición perdería sentido. El tiempo se mide con perf_counter, las latencias se ordenan, p95 y p99 se toman por posición en la lista ordenada, y el QPS es el cociente entre el número de consultas y el tiempo total de la ejecución.

Cómo aplicarlo en tu entorno

Para repetir la prueba hacen falta Docker con Compose, Python 3.10+ y unos 8 GB de memoria libre. No se necesitan cuentas en la nube.

La lógica práctica de la elección se desprende de la propia arquitectura. Si los datos ya viven en Postgres y la consulta debe combinar un filtro por campos relacionales con una búsqueda por similitud, pgvector evita tener un segundo sistema y su sincronización. Si se necesita filtrar a alta velocidad por campos JSON complejos, encaja Qdrant. Para colecciones de miles de millones de vectores se considera Milvus; para cero operación, Pinecone; y para vectorización integrada y BM25, Weaviate.

Un consejo más allá de la metodología: los vectores normales aleatorios carecen de la estructura de clústeres de los embeddings reales, y el script solo mide latencias. Antes de decidir una migración, ejecuta la misma prueba con tus propios embeddings y añade una comprobación de recall frente a la búsqueda exacta.