LanceDB cargó 100k embeddings de OpenAI 22 veces más rápido que pgvector, mientras que pgvector respondió a la misma carga de trabajo desde ocho clientes simultáneos 1.8 veces más rápido. La brecha en la latencia de un solo hilo y la eficiencia de almacenamiento también se inclinó a favor de LanceDB, ofreciendo a los desarrolladores una forma basada en datos para elegir un almacén de vectores.

Por qué un benchmark es importante ahora

La búsqueda vectorial ha pasado de los laboratorios de investigación a los servicios de producción, como los motores de recomendación y la generación aumentada por recuperación (RAG). La mayoría de los equipos ya utilizan PostgreSQL, por lo que la extensión pgvector promete la búsqueda de similitud sin necesidad de nueva infraestructura. Sin embargo, los almacenes dedicados como LanceDB prometen una menor latencia y un almacenamiento más económico. Los equipos deben elegir entre "añadirlo a lo que ya tenemos" o "ejecutar un motor diseñado específicamente para este propósito", una decisión que impacta en el coste y el rendimiento a medida que los conjuntos de datos crecen y las tasas de solicitudes aumentan.

Cómo se configuró la prueba

Ambos sistemas indexaron los mismos 100k vectores, cada uno de 1536 dimensiones, generados por el modelo de embeddings de OpenAI. Medimos la velocidad de ingesta, el uso de disco, la latencia de consulta de un solo hilo y el rendimiento (throughput) con ocho clientes concurrentes.

Resultados cara a cara

  • Velocidad de ingesta – LanceDB registró una ventaja de 22×.
  • Huella de disco – LanceDB almacenó los vectores en aproximadamente un tercio del espacio que utilizó pgvector.
  • Latencia de un solo hilo – Las consultas se ejecutaron aproximadamente el doble de rápido en LanceDB.
  • Escalabilidad de concurrencia – Con ocho clientes en paralelo, pgvector ofreció un rendimiento 1.8× mayor que LanceDB.

Raíces arquitectónicas de las diferencias

LanceDB es una biblioteca embebida que se ejecuta dentro del proceso de Python que aloja la aplicación. Todas las operaciones se mantienen dentro del proceso, por lo que los datos nunca cruzan un límite de red y el índice se actualiza con una sobrecarga mínima. Este diseño destaca en cargas de trabajo de una sola tarea, pero alcanza un límite cuando múltiples hilos de Python compiten por el Global Interpreter Lock (GIL), lo que bloquea la ejecución paralela real del bytecode de Python.

pgvector extiende PostgreSQL en el lado del servidor. Cada conexión de cliente inicia un proceso de servidor separado, evitando por completo el GIL. El planificador de PostgreSQL decide cómo satisfacer una búsqueda de similitud, y el servidor puede levantar muchos procesos para atender solicitudes concurrentes. Este aislamiento explica su mejor escalabilidad bajo carga.

Particularidades del filtrado y la planificación de consultas

Los pipelines de RAG en el mundo real suelen combinar la similitud vectorial con filtros tradicionales (por ejemplo, WHERE user_id = 42). LanceDB aplica un prefiltro que se comporta de manera predecible en cada ejecución. pgvector depende del planificador de consultas de PostgreSQL, que puede elegir un escaneo de índice rápido o recurrir a un escaneo exacto más lento dependiendo de las estadísticas. Ejecutar ANALYZE después de una carga masiva en una tabla de pgvector actualiza esas estadísticas; sin ello, el recall puede caer casi a cero, rompiendo efectivamente la búsqueda.

Cuándo tiene sentido cada opción

Elige pgvector si

  • Tu stack ya incluye PostgreSQL y quieres evitar añadir otro servicio.
  • Esperas muchos usuarios simultáneos o llamadas a la API.
  • Las garantías ACID y las herramientas de DBA familiares son importantes.

Elige LanceDB si

  • Tu flujo de trabajo es un pipeline de ML que ingiere nuevos embeddings con frecuencia.
  • Necesitas la ruta de escritura más rápida y baja latencia para agentes de solicitud única (por ejemplo, chatbots).
  • El coste de disco es una preocupación y puedes tolerar el límite de rendimiento de un solo hilo.

En resumen: Si lo que más importa es la velocidad de ingesta bruta, el almacenamiento mínimo y la latencia de solicitud única, LanceDB gana. Si debes atender a muchos usuarios a la vez y dependes de un despliegue de PostgreSQL existente, la ventaja de concurrencia de pgvector lo convierte en la opción más segura. Utiliza los números de este benchmark para ajustar el almacén a la métrica más crítica de tu producto.