Presentamos VDBBench 1.0: Benchmarking de VectorDB de código abierto con tus cargas de trabajo de producción del mundo real
La mayoría de los benchmarks de bases de datos vectoriales prueban con datos estáticos e índices preconstruidos. Pero los sistemas de producción no funcionan así: los datos fluyen continuamente mientras los usuarios ejecutan consultas, los filtros fragmentan los índices y las características de rendimiento cambian drásticamente bajo cargas concurrentes de lectura/escritura.
Hoy lanzamos VDBBench 1.0, un benchmark de código abierto diseñado desde cero para probar bases de datos vectoriales en condiciones de producción realistas: ingesta de datos en streaming, filtrado de metadatos con selectividad variable y cargas de trabajo concurrentes que revelan los cuellos de botella reales del sistema.
Descargar VDBBench 1.0 → | Ver Leaderboard →
Por qué los benchmarks actuales son engañosos
Seamos honestos: hay un fenómeno extraño en nuestra industria. Todo el mundo habla de "no manipular los benchmarks", pero muchos participan exactamente en ese comportamiento. Desde que el mercado de bases de datos vectoriales explotó en 2023, hemos visto numerosos ejemplos de sistemas que "lucen de maravilla en los benchmarks" pero "fracasan estrepitosamente" en producción, desperdiciando tiempo de ingeniería y dañando la credibilidad de los proyectos.
Hemos presenciado esta desconexión de primera mano. Por ejemplo, Elasticsearch presume velocidades de consulta a nivel de milisegundos, pero detrás de escena, puede tardar más de 20 horas solo en optimizar su índice. ¿Qué sistema de producción puede tolerar semejante tiempo de inactividad?
El problema surge de tres fallas fundamentales:
Conjuntos de datos obsoletos: Muchos benchmarks todavía dependen de conjuntos de datos heredados como SIFT (128 dimensiones), mientras que los embeddings modernos van de 768 a 3.072 dimensiones. Las características de rendimiento de los sistemas que operan con vectores 128D frente a 1024D+ son fundamentalmente diferentes: los patrones de acceso a memoria, la eficiencia del índice y la complejidad computacional cambian drásticamente.
Métricas de vanidad: Los benchmarks se centran en la latencia promedio o el QPS máximo, creando una imagen distorsionada. Un sistema con una latencia promedio de 10 ms pero una latencia P99 de 2 segundos crea una experiencia de usuario terrible. El rendimiento máximo medido durante 30 segundos no te dice nada sobre el rendimiento sostenido.
Escenarios demasiado simplificados: La mayoría de los benchmarks prueban flujos de trabajo básicos de "escribir datos, construir índice, consultar", esencialmente pruebas de nivel "Hello World". La producción real implica ingesta continua de datos mientras se atienden consultas, filtrado complejo de metadatos que fragmenta índices y operaciones concurrentes de lectura/escritura que compiten por recursos.
¿Qué hay de nuevo en VDBBench 1.0?
VDBBench no se limita a iterar sobre filosofías de benchmarking obsoletas: reconstruye el concepto desde primeros principios con una creencia guía: un benchmark solo es valioso si predice el comportamiento real en producción.
Hemos diseñado VDBBench para replicar fielmente condiciones del mundo real en tres dimensiones críticas: autenticidad de los datos, patrones de carga de trabajo y metodologías de medición del rendimiento.
Veamos más de cerca qué nuevas funciones aporta.
🚀 Dashboard rediseñado con visualizaciones relevantes para producción
La mayoría de los benchmarks se centran únicamente en la salida de datos en bruto, pero lo que importa es cómo los ingenieros interpretan esos resultados y actúan en consecuencia. Rediseñamos la interfaz de usuario para priorizar la claridad y la interactividad, permitiéndote detectar brechas de rendimiento entre sistemas y tomar decisiones rápidas de infraestructura.
El nuevo dashboard visualiza no solo cifras de rendimiento, sino las relaciones entre ellas: cómo se degrada el QPS bajo distintos niveles de selectividad de filtros, cómo fluctúa el recall durante la ingesta en streaming y cómo las distribuciones de latencia revelan características de estabilidad del sistema.
Dashboard de VDBbench
Hemos vuelto a probar las principales plataformas de bases de datos vectoriales, incluidas Milvus, Zilliz Cloud, Elastic Cloud, Qdrant Cloud, Pinecone y OpenSearch, con sus configuraciones más recientes y ajustes recomendados, garantizando que todos los datos de referencia reflejen las capacidades actuales. Todos los resultados de las pruebas están disponibles en la Clasificación de VDBBench.
🏷️ Filtrado por etiquetas: el asesino oculto del rendimiento
Las consultas del mundo real rara vez ocurren de forma aislada. Las aplicaciones combinan la similitud vectorial con el filtrado de metadatos ("encuentra zapatos que se parezcan a esta foto pero cuesten menos de 100 dólares"). Esta búsqueda vectorial filtrada crea desafíos únicos que la mayoría de los benchmarks ignoran por completo.
Las búsquedas filtradas introducen complejidad en dos áreas críticas:
Complejidad del filtro: Más campos escalares y condiciones lógicas complejas aumentan las demandas computacionales y pueden causar una recuperación insuficiente y fragmentación del índice de grafos.
Selectividad del filtro: Este es el "asesino oculto del rendimiento" que hemos verificado repetidamente en producción. Cuando las condiciones de filtrado se vuelven altamente selectivas (filtrando más del 99% de los datos), las velocidades de consulta pueden fluctuar por órdenes de magnitud, y la recuperación puede volverse inestable a medida que las estructuras de índice tienen dificultades con conjuntos de resultados dispersos.
VDBBench prueba sistemáticamente varios niveles de selectividad de filtrado (del 50% al 99,9%), proporcionando un perfil de rendimiento completo bajo este patrón crítico de producción. Los resultados a menudo revelan caídas drásticas de rendimiento que nunca aparecerían en los benchmarks tradicionales.
Ejemplo: En las pruebas de Cohere 1M, Milvus mantuvo una recuperación consistentemente alta en todos los niveles de selectividad de filtrado, mientras que OpenSearch mostró un rendimiento inestable con una recuperación que fluctuó significativamente bajo diferentes condiciones de filtrado, cayendo por debajo de 0,8 de recuperación en muchos casos, lo cual es inaceptable para la mayoría de los entornos de producción.
Figura: QPS y recuperación de Milvus y OpenSearch en diferentes niveles de selectividad de filtrado (prueba Cohere 1M).
🌊 Lectura/escritura en streaming: más allá de las pruebas de índices estáticos
Los sistemas de producción rara vez disfrutan del lujo de datos estáticos. La nueva información fluye continuamente mientras se ejecutan las búsquedas, un escenario en el que muchas bases de datos por lo demás impresionantes colapsan bajo la doble presión de mantener el rendimiento de búsqueda mientras gestionan escrituras continuas.
Los escenarios de streaming de VDBBench simulan operaciones paralelas reales, ayudando a los desarrolladores a comprender la estabilidad del sistema en entornos de alta concurrencia, especialmente cómo la escritura de datos afecta el rendimiento de las consultas y cómo evoluciona el rendimiento a medida que aumenta el volumen de datos.
Para garantizar comparaciones justas entre diferentes sistemas, VDBBench utiliza un enfoque estructurado:
Configurar tasas de escritura controladas que reflejen las cargas de trabajo de producción objetivo (por ejemplo, 500 filas/seg distribuidas en 5 procesos paralelos)
Activar operaciones de búsqueda después de cada 10% de ingesta de datos, alternando entre modos seriales y concurrentes
Registrar métricas completas: distribuciones de latencia (incluido P99), QPS sostenidos y precisión de recuperación
Seguir la evolución del rendimiento a lo largo del tiempo a medida que aumentan el volumen de datos y el estrés del sistema
Esta prueba de carga controlada e incremental revela qué tan bien los sistemas mantienen la estabilidad y la precisión bajo una ingesta continua, algo que los benchmarks tradicionales rara vez capturan.
Ejemplo: En las pruebas de streaming de Cohere 10M, Pinecone mantuvo QPS y recuperación más altos durante todo el ciclo de escritura en comparación con Elasticsearch. En particular, el rendimiento de Pinecone mejoró significativamente después de completarse la ingesta, demostrando una gran estabilidad bajo carga sostenida, mientras que Elasticsearch mostró un comportamiento más errático durante las fases de ingesta activa.
Figura: QPS y recuperación de Pinecone frente a Elasticsearch en la prueba de streaming Cohere 10M (tasa de ingesta de 500 filas/s).
VDBBench va aún más allá al admitir un paso opcional de optimización, lo que permite a los usuarios comparar el rendimiento de búsqueda en streaming antes y después de la optimización del índice. También rastrea e informa el tiempo real dedicado a cada etapa, ofreciendo información más profunda sobre la eficiencia del sistema y su comportamiento en condiciones similares a producción.
Figura: QPS y Recall de Pinecone vs. Elasticsearch en la prueba de streaming Cohere 10M después de la optimización (tasa de ingesta de 500 filas/s)
Como se muestra en nuestras pruebas, Elasticsearch superó a Pinecone en QPS—después de la optimización del índice. Pero cuando el eje x refleja el tiempo transcurrido real, queda claro que Elasticsearch tardó significativamente más en alcanzar ese rendimiento. En producción, ese retraso importa. Esta comparación revela una compensación clave: rendimiento máximo vs. tiempo hasta estar listo para servir.
🔬 Conjuntos de datos modernos que reflejan las cargas de trabajo actuales de IA
Hemos renovado por completo los conjuntos de datos utilizados para la evaluación comparativa de bases de datos vectoriales. En lugar de conjuntos de prueba heredados como SIFT y GloVe, VDBBench utiliza vectores generados a partir de modelos de embeddings de última generación como OpenAI y Cohere, que impulsan las aplicaciones de IA actuales.
Para garantizar la relevancia, especialmente para casos de uso como la Generación Aumentada por Recuperación (RAG), seleccionamos corpus que reflejan escenarios empresariales y específicos de dominio del mundo real:
| Corpus | Modelo de embedding | Dimensiones | Tamaño | Caso de uso |
|---|---|---|---|---|
| Wikipedia | Cohere V2 | 768 | 1M / 10M | Base de conocimiento general |
| BioASQ | Cohere V3 | 1024 | 1M / 10M | Específico de dominio (biomédico) |
| C4 | OpenAI | 1536 | 500K / 5M | Procesamiento de texto a escala web |
| MSMarco V2 | udever-bloom-1b1 | 1536 | 1M / 10M / 138M | Búsqueda a gran escala |
Estos conjuntos de datos simulan mejor los datos vectoriales actuales de alto volumen y alta dimensionalidad, lo que permite pruebas realistas de eficiencia de almacenamiento, rendimiento de consultas y precisión de recuperación en condiciones que coinciden con las cargas de trabajo modernas de IA.
⚙️ Soporte para conjuntos de datos personalizados para pruebas específicas de la industria
Cada negocio es único. La industria financiera podría necesitar pruebas centradas en embeddings de transacciones, mientras que las plataformas sociales se preocupan más por los vectores de comportamiento de usuario. VDBBench te permite realizar benchmarks con tus propios datos generados a partir de tus modelos de embeddings específicos para tus cargas de trabajo específicas.
Puedes personalizar:
Dimensiones vectoriales y tipos de datos
Esquema de metadatos y patrones de filtrado
Volumen de datos y patrones de ingesta
Distribuciones de consultas que coincidan con tu tráfico de producción
Al fin y al cabo, ningún conjunto de datos cuenta una historia mejor que tus propios datos de producción.
Cómo VDBBench mide lo que realmente importa en producción
Diseño de métricas enfocado en producción
VDBBench prioriza métricas que reflejan el rendimiento del mundo real, no solo resultados de laboratorio. Hemos rediseñado la evaluación comparativa en torno a lo que realmente importa en entornos de producción: fiabilidad bajo carga, características de latencia de cola, rendimiento sostenido y preservación de la precisión.
Latencia P95/P99 para la experiencia real del usuario: La latencia promedio/mediana oculta los valores atípicos que frustran a los usuarios reales y pueden indicar inestabilidad subyacente del sistema. VDBBench se centra en la latencia de cola como P95/P99, revelando qué rendimiento alcanzará realmente el 95% o el 99% de tus consultas. Esto es crucial para la planificación de SLA y para comprender la experiencia de usuario en el peor de los casos.
Rendimiento sostenible bajo carga: Un sistema que funciona bien durante 5 segundos no es suficiente en producción. VDBBench aumenta gradualmente la concurrencia para encontrar el máximo de consultas sostenibles por segundo (
max_qps) de tu base de datos, no el número máximo bajo condiciones breves e ideales. Esta metodología revela qué tan bien se mantiene tu sistema a lo largo del tiempo y ayuda con una planificación de capacidad realista.Recall equilibrado con rendimiento: La velocidad sin precisión no significa nada. Cada cifra de rendimiento en VDBBench está acompañada de mediciones de recall, para que sepas exactamente cuánta relevancia estás sacrificando por throughput. Esto permite comparaciones justas, de igual a igual, entre sistemas con compensaciones internas muy diferentes.
Metodología de prueba que refleja la realidad
Una innovación clave en el diseño de VDBBench es la separación de las pruebas en serie y concurrentes, lo que ayuda a capturar cómo se comportan los sistemas bajo diferentes tipos de carga y revela características de rendimiento que importan para distintos casos de uso.
Separación de la medición de latencia:
serial_latency_p99mide el rendimiento del sistema bajo una carga mínima, donde solo se procesa una solicitud a la vez. Esto representa el mejor escenario para la latencia y ayuda a identificar las capacidades base del sistema.conc_latency_p99captura el comportamiento del sistema bajo condiciones realistas de alta concurrencia, donde múltiples solicitudes llegan simultáneamente y compiten por los recursos del sistema.
Estructura de benchmark en dos fases:
Prueba en serie: Ejecución de un solo proceso con 1,000 consultas que establece el rendimiento y la precisión base, reportando tanto
serial_latency_p99como el recall. Esta fase ayuda a identificar el techo teórico de rendimiento.Prueba de concurrencia: Simula un entorno de producción bajo carga sostenida con varias innovaciones clave:
Simulación realista de clientes: Cada proceso de prueba opera de forma independiente con su propia conexión y conjunto de consultas, evitando interferencias de estado compartido que podrían distorsionar los resultados
Inicio sincronizado: Todos los procesos comienzan simultáneamente, asegurando que el QPS medido refleje con precisión los niveles de concurrencia declarados
Conjuntos de consultas independientes: Evita tasas de acierto de caché poco realistas que no reflejan la diversidad de consultas en producción
Estos métodos cuidadosamente estructurados garantizan que los valores de max_qps y conc_latency_p99 reportados por VDBBench sean tanto precisos como relevantes para producción, proporcionando información significativa para la planificación de capacidad en producción y el diseño de sistemas.
Primeros pasos con VDBBench 1.0
VDBBench 1.0 representa un cambio fundamental hacia benchmarking relevante para producción. Al cubrir escritura continua de datos, filtrado de metadatos con selectividad variable y cargas de streaming bajo patrones de acceso concurrente, proporciona la aproximación más cercana a entornos de producción reales disponible hoy.
La brecha entre los resultados de benchmarks y el rendimiento en el mundo real no debería ser un juego de adivinanzas. Si estás planeando desplegar una base de datos vectorial en producción, vale la pena entender cómo se comporta más allá de pruebas de laboratorio idealizadas. VDBBench es open-source, transparente y está diseñado para apoyar comparaciones significativas, de igual a igual.
No te dejes influir por cifras impresionantes que no se traducen en valor de producción. Usa VDBBench 1.0 para probar escenarios que importan a tu negocio, con tus datos, bajo condiciones que reflejen tu carga de trabajo real. La era de los benchmarks engañosos en la evaluación de bases de datos vectoriales está llegando a su fin: es hora de tomar decisiones basadas en datos relevantes para producción.
Prueba VDBBench con tus propias cargas de trabajo: https://github.com/zilliztech/VectorDBBench
Consulta los resultados de pruebas de las principales bases de datos vectoriales: VDBBench Leaderboard
¿Tienes preguntas o quieres compartir tus resultados? Únete a la conversación en GitHub o conecta con nuestra comunidad en Discord.
Sigue leyendo
Introducing Loon: A New Storage Engine for Vector Data That Never Stops Changing
Loon is a new storage engine for Milvus 3.0 and Zilliz Vector Lakebase, built to manage evolving vector datasets with ColumnGroups, row ID alignment, and Manifests.
Milvus/Zilliz + Surveillance: How Vector Databases Transform Multi-Camera Tracking
See how Milvus vector database enhances multi-camera tracking with similarity-based matching for better surveillance in retail, warehouses and transport hubs.
Vector Databases vs. Key-Value Databases
Use a vector database for AI-powered similarity search; use a key-value database for high-throughput, low-latency simple data lookups.