VDBBench añade benchmarking consciente de los costos para bases de datos vectoriales
El año pasado, lanzamos VectorDBBench 1.0 para acercar la evaluación comparativa de bases de datos vectoriales a las cargas de trabajo de producción. En lugar de probar solo el QPS máximo en datos de referencia fijos, VectorDBBench (también conocido como VDBBench) permite a los equipos evaluar bases de datos vectoriales utilizando patrones de carga de trabajo que reflejan más de cerca sus propios sistemas de producción: ingesta, filtrado, recall, latencia, concurrencia y conjuntos de datos personalizados.
La versión más reciente de VDBBench añade una nueva dimensión: el costo.
Los equipos de producción rara vez eligen una base de datos vectorial solo por el rendimiento. Necesitan saber cuánto cuesta alcanzar un QPS objetivo, cómo se comporta el P99 bajo ese modelo de costos, cuándo los datos insertados se vuelven buscables, cuándo están completamente indexados, cómo afecta el tamaño del payload a la búsqueda, cómo se comporta el sistema con muchos tenants y qué ocurre en la primera consulta después de estar inactivo. Esas preguntas ahora forman parte de VDBBench.
Para mostrar cómo funcionan en la práctica estos nuevos benchmarks conscientes del costo, probamos tres productos de bases de datos vectoriales administradas que se evalúan comúnmente: Zilliz Cloud, Turbopuffer y Pinecone. Los resultados se publican en el nuevo VDBBench Cost Leaderboard, con gráficos y tablas que comparan la preparación para inserciones, la búsqueda con payload, la búsqueda multi-tenant, la latencia en frío y las compensaciones entre costo y rendimiento.
El leaderboard es solo una forma de leer los resultados: es una instantánea de tres productos en un momento determinado. Como VDBBench es de código abierto, los equipos también pueden reproducir estos casos, evaluar productos que no están en el leaderboard o adaptar las cargas de trabajo a sus propios datos similares a los de producción.
El objetivo no es coronar a un ganador universal, sino ayudar a los equipos a elegir la base de datos vectorial que mejor se ajuste a su carga de trabajo, sus objetivos de rendimiento y su presupuesto.
- Referencias: VectorDBBench GitHub | VDBBench Leaderboards
Novedades en VDBBench
Esta versión añade cuatro casos de benchmark orientados a la nube que miden comportamientos de producción que los leaderboards de QPS máximo suelen pasar por alto.
| Caso | Qué mide | Por qué importa |
|---|---|---|
| CloudInsertCase | Finalización de inserción, estado buscable, estado completamente indexado y costo de escritura | La frescura y el costo de backfill importan para RAG, catálogos y memoria de agentes |
| CloudPayloadSearchCase | QPS, latencia P99, recall y forma del payload de respuesta | Devolver vectores o metadatos puede cambiar la superficie de costos de búsqueda |
| MultitenantSearchCase | Rendimiento a través de muchos tenants o namespaces | Las cargas de trabajo SaaS estresan el enrutamiento y el comportamiento de particiones de forma distinta a la búsqueda de un solo tenant |
| CloudColdLatencyCase | Primera consulta después de inactividad frente a ruta de consulta en caliente | El comportamiento de arranque en frío importa para tenants de baja frecuencia y memoria de agentes |
Además de estos casos, el Cost Leaderboard añade una vista costo-Pareto que modela los costos operativos en niveles de QPS objetivo bajo los límites de servicio medidos de cada producto, porque las decisiones de compra suelen depender del punto en que se cruzan rendimiento y costo.
El VDBBench Cost Leaderboard utiliza estos casos para comparar públicamente productos administrados. Como los casos se distribuyen en el VDBBench de código abierto, los equipos pueden reutilizarlos para su propia evaluación, incluidos productos y cargas de trabajo que no aparecen en el leaderboard.
A quién probamos: Zilliz Cloud vs. Turbopuffer vs. Pinecone
Para esta primera ejecución consciente del costo, probamos tres productos de bases de datos vectoriales administradas que se evalúan comúnmente. Todos los productos se evaluaron el 10 de mayo de 2026 en AWS US West (us-west-2). Sus modelos operativos difieren, por lo que los resultados deben interpretarse en términos de ajuste a la carga de trabajo, en lugar de como una clasificación única.
| Producto | Rol en este benchmark |
|---|---|
| Zilliz Cloud | Base de datos vectorial en la nube gestionada y lakebase vectorial de los creadores de Milvus, probada en sus configuraciones Tiered y Capacity |
| Turbopuffer | Base de datos vectorial serverless probada en modos sin fijación y con fijación |
| Pinecone Serverless | Base de datos vectorial serverless madura y de baja operación usada como punto de referencia común de producción |
Figura 1. Resumen direccional de adecuación a la carga de trabajo basado en extractos del benchmark y modelado de costos. Las puntuaciones están normalizadas para la comparación entre dimensiones de carga de trabajo y no deben leerse como clasificaciones absolutas universales.
El gráfico de radar resume la señal direccional de los extractos del benchmark y el modelo de costos. No es una tabla de puntuación absoluta; es un mapa de dónde tiende a ser más fuerte cada producto.
- Zilliz Cloud Tiered es la línea económica de servicio activo que escala a medida que aumenta la utilización.
- Zilliz Cloud Capacity es el perfil de mayor control para servicio predecible, frescura y comportamiento en frío.
- Turbopuffer es más fuerte donde la economía serverless medida por uso y el rendimiento orientado a namespaces coinciden con la carga de trabajo.
- Pinecone sigue siendo una referencia serverless útil de baja operación, incluso cuando no es la frontera de costo-rendimiento en una prueba específica.
El patrón principal es claro. La economía serverless puede ser atractiva con QPS sostenido bajo. La capacidad provisionada se vuelve más competitiva a medida que aumenta la utilización. La frescura, la búsqueda filtrada, el tamaño de la carga útil, el número de tenants y el comportamiento en frío pueden influir en la decisión.
Conjuntos de datos y cargas de trabajo
Los casos conscientes del costo usan dos formas de carga de trabajo.
- LAION 100M de tenant único: 100 millones de vectores densos de 768 dimensiones. Esto representa una gran colección de producción donde el tamaño de la carga útil, los filtros, el recall y el QPS sostenido importan.
- Cohere 10M multitenant: 10 millones de vectores densos de 768 dimensiones, divididos aleatoriamente entre 1.000 tenants — aproximadamente 10K vectores por tenant. Esto representa cargas de trabajo de estilo SaaS en las que cada tenant tiene un conjunto de datos más pequeño, pero el sistema debe enrutar y servir eficientemente muchos namespaces o particiones de tenant.
Los extractos a continuación muestran la forma de los hallazgos. El Cost Leaderboard y el repositorio VectorDBBench siguen siendo la fuente de las matrices completas, las definiciones de clientes y los detalles de reproducción.
CloudInsertCase: Insertado no siempre significa listo
El rendimiento de inserción no es un solo número. Una base de datos vectorial gestionada puede aceptar datos del cliente antes de que esos datos sean seguros para buscar a través de la ruta de índice prevista. Para cargas de trabajo de producción, los equipos necesitan saber cuándo se completa la operación de inserción, cuándo los datos se vuelven buscables y cuándo la indexación en segundo plano se ha puesto completamente al día.
CloudInsertCase mide el ciclo de vida de escritura a servicio. Esto importa para actualizaciones de corpus RAG, actualizaciones de catálogos de productos, escrituras de memoria de agentes y backfills de datos. En estos sistemas, "inserción aceptada" no es suficiente. La pregunta operativa es cuándo los datos recién escritos pueden buscarse de manera confiable con rendimiento de producción.
| Producto / modo | Tamaño de lote | Tiempo de inserción | Espera hasta ser buscable | Espera hasta indexación completa | Costo de escritura |
|---|---|---|---|---|---|
| Zilliz Cloud Capacity 12CU | 10.000 | 3,2 h | 0 ms | 1,9 min | $9,50 |
| Zilliz Cloud Tiered 4CU | 10.000 | 4,1 h | 0 ms | 10,9 min | $6,34 |
| Turbopuffer (backpressure desactivado) | 10.000 | 1,8 h | 6,4 h | 2,0 min | $302 |
| Pinecone Serverless | 10.000 | 72,4 h | 0 ms | 127 ms | $1.180 |
Tabla 1. Extracto de inserción de LAION 100M con lotes de 10k. Los costos y tiempos provienen de la ejecución actual del leaderboard. Para las configuraciones provisionadas de Zilliz, el costo de escritura es el costo de CU-hora consumido durante la ventana de carga e indexación; para Turbopuffer y Pinecone, es el cargo de escritura medido. Lea los tiempos junto con las definiciones del cliente para los estados insertado, buscable y completamente indexado (definidos por cliente en el código fuente de VDBBench).
El tamaño de lote cambia los números para distintos productos.
- Turbopuffer muestra una fuerte ingesta bruta en lotes grandes, especialmente con la contrapresión desactivada — su modo de ingesta más agresivo. En la ruta batch-10k, completa la inserción rápidamente, pero la espera hasta que los datos sean buscables domina la ventana completa de preparación.
- Zilliz Cloud es más estable entre tamaños de lote. En las configuraciones Capacity y Tiered probadas, los datos se vuelven buscables inmediatamente después de que se completa la inserción, y la espera restante hasta estar completamente indexados se mide en minutos.
- Pinecone Serverless es la referencia de ingesta masiva más lenta en esta prueba. Una vez que se aceptan los datos, la espera adicional hasta ser buscables y estar completamente indexados es efectivamente cero en estas ejecuciones, pero la etapa de inserción en sí tarda mucho más.
La lectura del producto está determinada por la carga de trabajo.
- Zilliz encaja en flujos de trabajo donde los datos recientes deben ser rápidamente buscables e indexados a un costo predecible.
- Turbopuffer encaja en grandes cargas retrospectivas aceptadas cuando la carga de trabajo puede tolerar una ventana de preparación más larga.
- Pinecone encaja en patrones de ingesta serverless de menor volumen donde la simplicidad operativa importa más que la velocidad o el costo de carga masiva.
La carga masiva también es un evento de costo. En este caso de inserción LAION 100M, las configuraciones de Zilliz mantienen el costo del lado de escritura en el rango de dólares de un solo dígito para la ruta batch-10k probada. Turbopuffer se modela en torno a $302. Pinecone Serverless se modela en torno a $1,180. Eso no hace que un modelo de precios sea universalmente mejor. Significa que la economía de inserción depende de la frecuencia con la que la carga de trabajo ejecuta esa ruta.
Figura 2. Ciclo de vida de inserción para LAION 100M con batch 10k: tiempo de inserción, espera hasta ser buscable, espera hasta estar completamente indexado y costo de escritura modelado por producto.
CloudPayloadSearchCase: La carga útil cambia la superficie de búsqueda
Una vez que los datos son buscables, la siguiente pregunta no es solo cuántas consultas por segundo puede manejar la base de datos. La forma de la respuesta importa. Devolver solo IDs es muy distinto de devolver metadatos o vectores sin procesar. Un vector de 768 dimensiones puede añadir miles de bytes a cada resultado. Con topK=100, el tamaño de la carga útil puede convertirse en un factor importante en el costo y la latencia de las consultas.
CloudPayloadSearchCase prueba LAION 100M de un solo inquilino bajo distintas cargas útiles de respuesta y formas de filtro. La lectura combina el QPS máximo concurrente, la latencia P99 en esa concurrencia, el tipo de carga útil y el recall, cuando está disponible.
Una nota sobre la lectura de las tablas: P99 aquí se mide en la concurrencia máxima — el punto de saturación que produce el QPS máximo de cada producto — no en un punto operativo cómodo de nivel de servicio. Muestra cómo se comporta una configuración en su límite medido.
| Producto | Latencia P99 @ concurrencia máxima | QPS máximo | recall@10 |
|---|---|---|---|
| Zilliz Cloud Capacity 32CU | 158 ms | 786.1 | 0.9728 |
| turbopuffer | 2.34 s | 395.7 | 0.9321 |
| Zilliz Cloud Capacity 12CU | 299 ms | 376.0 | 0.9723 |
| Turbopuffer pinned | 3.30 s | 68.2 | 0.9321 |
| Zilliz Cloud Tiered 4CU | 5.57 s | 49.2 | 0.9510 |
| Pinecone Serverless | 4.85 s | 4.6 | 0.9609 |
Tabla 2. LAION 100M de un solo inquilino, sin filtro, solo IDs, topK 100. Nota sobre Pinecone: su rendimiento en este caso de un solo inquilino está limitado por la restricción de unidades de lectura del lado del servidor, por lo que la ejecución alcanza como máximo una concurrencia de 4–5, frente a 80 para los otros productos. Lea sus filas como una referencia serverless con ritmo controlado en lugar de como un resultado de saturación.
La configuración importa. Con 12CU, Zilliz Capacity y Turbopuffer están cerca en QPS bruto en este caso amplio de solo IDs, mientras que Zilliz va por delante en recall y latencia P99. Con 32CU, Zilliz Capacity supera el resultado probado de Turbopuffer para esta carga de trabajo de un solo inquilino.
Figura 3. Búsqueda de LAION 100M de un solo inquilino con respuestas de solo IDs. Esta vista compara el QPS máximo concurrente, la latencia P99 y recall@10 entre las configuraciones gestionadas probadas.
La pregunta no es solo qué producto es más rápido en una configuración. Es cómo cambia el rendimiento cuando un equipo compra más capacidad, cambia la forma del payload o necesita un objetivo de recall. Cuando la consulta devuelve payloads de vectores sin procesar, el throughput puede cambiar de forma significativa.
| Producto | QPS solo IDs | QPS con payload de vectores | Recall |
|---|---|---|---|
| Zilliz Cloud Tiered 4CU | 49.2 | 44.0 | 0.9510 |
| Zilliz Cloud Capacity 12CU | 376.0 | 229.4 | 0.9723 |
| Zilliz Cloud Capacity 32CU | 786.1 | 531.4 | 0.9728 |
| turbopuffer | 395.7 | 382.2 | 0.9321 |
| Pinecone Serverless | 4.6 | 4.5 | 0.9609 |
Tabla 3. Extracto de payload para recuperación amplia sin filtros. Los equipos deberían hacer benchmarks con la forma de payload que su aplicación realmente devuelve, no solo con búsqueda solo de IDs.
Búsqueda filtrada: donde importa la selectividad
Muchas cargas de trabajo de búsqueda vectorial en producción tienen permisos o filtros. Un copiloto de soporte puede buscar solo documentos que el usuario tiene permitido ver. Un sistema de recomendación puede filtrar por región, categoría, vendedor o disponibilidad. Una aplicación de búsqueda empresarial puede aplicar restricciones de inquilino, control de acceso, frescura y tipo de documento antes de clasificar los resultados.
Estos filtros no son cosméticos. Cambian la ruta de ejecución. En el punto de estrés de filtro entero del 99.9% más payload de vectores, el comportamiento del producto cambia drásticamente.
| Producto | QPS máximo | Recall | Latencia P99 |
|---|---|---|---|
| Zilliz Cloud Tiered 4CU | 955.7 | 0.9423 | 0.16 s |
| Zilliz Cloud Capacity 12CU | 933.0 | 0.9781 | 0.12 s |
| turbopuffer | 45.1 | 0.9436 | 7.03 s |
| Pinecone Serverless | 4.8 | —* | 3.30 s |
Tabla 4. Punto de estrés de filtro selectivo de un solo inquilino: filtro entero del 99.9% con payload de vectores. El recall de la ejecución de Pinecone Serverless en este punto de estrés aún no estaba disponible en el momento de la publicación; su QPS y latencia provienen de la ejecución medida.
Este es uno de los ejemplos más claros de por qué la evaluación consciente del coste necesita múltiples formas de carga de trabajo. Un producto que funciona bien en la recuperación amplia sin filtros puede no ser la mejor opción para la búsqueda selectiva filtrada. Para búsqueda con permisos, RAG con mucho control de acceso o cargas de trabajo con alta selectividad de filtros, las filas filtradas pueden importar más que las filas sin filtros.
MultitenantSearchCase: muchos inquilinos pequeños se comportan de manera diferente
Los benchmarks de un solo inquilino no capturan todas las cargas de trabajo en la nube.
Muchas aplicaciones de IA tienen forma de SaaS. Un producto puede servir a miles de inquilinos, cada uno con un conjunto de datos más pequeño. El desafío operativo no es solo la búsqueda vectorial dentro de una única colección grande. Es el enrutamiento, el aislamiento, la gestión de namespaces y el mantenimiento del throughput a través de muchas particiones pequeñas.
El caso multiinquilino usa el conjunto de datos Cohere 10M dividido entre 1,000 inquilinos. La forma de la consulta usa topK 50 y compara filas solo de IDs, con payload de vectores y filtradas.
Dos notas de configuración determinan cómo leer esta tabla.
Primero, las configuraciones de Zilliz aquí son intencionadamente pequeñas — Tiered 1CU y Capacity 2CU, apenas lo suficiente para alojar el conjunto de datos Cohere 10M. El caso de un solo inquilino anterior ya muestra que el QPS de Zilliz escala con el recuento de CU; la pregunta que plantea este caso es la rentabilidad en una configuración dimensionada para los datos, no el throughput máximo.
Segundo, la columna de Pinecone es una ejecución separada de baja concurrencia (concurrencia 4), no normalizada frente a las filas de mayor concurrencia, así que trátala como contexto en lugar de una comparación directa.
Figura 4. Búsqueda multiinquilino en Cohere 10M a través de 1,000 inquilinos, sin filtros, solo IDs, topK 50. La vista compara la latencia P99 serial y el QPS concurrente máximo entre las configuraciones probadas; la tabla de abajo añade variaciones de payload y filtros.
| Caso | Zilliz Tiered 1CU | Zilliz Capacity 2CU | turbopuffer | Pinecone (c4 run) |
|---|---|---|---|---|
| Sin filtrar, solo IDs | 481 | 889 | 3,855 | 569 |
| Sin filtrar, vector | 34 | 371 | 1,775 | 542 |
| Filtro de enteros 99.9%, vector | 625 | 1,307 | 3,835 | 526 |
| Etiqueta escalar 1%, vector | 152 | 588 | 1,767 | 600 |
| Etiqueta escalar 50%, vector | 29 | 317 | 1,760 | 562 |
Tabla 5. Extracto de búsqueda multiinquilino en 1,000 inquilinos, topK 50.
En este modo, Turbopuffer es sólido en todos los aspectos. Alcanza 3,855 QPS en una búsqueda sin filtrar de solo IDs y 3,835 QPS en la fila selectiva de filtro de enteros/vector. Zilliz Cloud Capacity 2CU sigue siendo el perfil de Zilliz más fuerte en este extracto, alcanzando 889 QPS en solo IDs sin filtrar y 1,307 QPS en la fila de filtro de enteros 99.9%/vector.
La lectura del producto vuelve a estar determinada por la carga de trabajo. Turbopuffer encaja bien con muchos inquilinos ligeros y rendimiento orientado a espacios de nombres. Zilliz es más fuerte cuando las cargas de trabajo están filtradas, sujetas a permisos, son sensibles al recall o más pesadas por inquilino, especialmente cuando los equipos pueden elegir una configuración de Zilliz Capacity que coincida con el objetivo de servicio.
CloudColdLatencyCase: La primera consulta después de estar inactivo
Los bucles de benchmark en caliente pueden ocultar el comportamiento en frío. Para muchas aplicaciones de IA en producción, especialmente memoria de agentes, RAG de cola larga y cargas de trabajo de inquilinos de baja frecuencia, la primera consulta después de estar inactivo importa. Un sistema puede parecer rápido después del calentamiento, pero añade segundos de latencia cuando se vuelve a acceder a una colección, espacio de nombres o ruta de caché en frío.
CloudColdLatencyCase aísla ese comportamiento. Mide la primera consulta contra una colección que ha estado inactiva durante al menos 24 horas — tiempo suficiente para que las cachés y las rutas de servicio se enfríen tanto como lo hacen de forma realista — y la compara con la primera consulta en la ruta calentada de la misma ejecución.
Figura 5. Latencia de la primera consulta después de estar inactivo frente a la ruta de consulta calentada para búsqueda LAION 100M sin filtrar. La relación frío/caliente destaca si un producto tiene una penalización material en la primera consulta después de estar inactivo.
| Producto | Primera consulta después de estar inactivo | Primera consulta en caliente | Relación frío/caliente |
|---|---|---|---|
| Zilliz Cloud Capacity 12CU | 55 ms | 54 ms | 1.01x |
| Turbopuffer pinned | 64 ms | 45 ms | 1.42x |
| Zilliz Cloud Tiered 4CU | 122 ms | 57 ms | 2.16x |
| Pinecone Serverless | 271 ms | 60 ms | 4.52x |
| turbopuffer | 2,048 ms | 322 ms | 6.36x |
Tabla 6. Extracto de latencia de primera consulta en frío y en caliente para LAION 100M sin filtrar. El caso informa la latencia de primera consulta en lugar de percentiles de cola: las relaciones frío/caliente en P99 tienden a captar ruido de red en consultas posteriores que no se reproduce de forma fiable, por lo que la clasificación utiliza la definición más estricta de primera consulta.
En el caso actual de latencia en frío sin filtrar, Zilliz Cloud Capacity 12CU muestra el perfil frío-a-caliente más ajustado: 55 ms en frío y 54 ms en caliente, o una relación de 1.01x. Turbopuffer pinned también tiene un perfil sólido con 64 ms en frío y 45 ms en caliente. Turbopuffer sin fijar muestra una penalización en frío mayor: 2,048 ms en frío y 322 ms en caliente, o una relación de 6.36x.
La latencia en frío siempre debe leerse junto con el coste. Las réplicas fijadas y la capacidad aprovisionada pueden reducir las penalizaciones de primer acceso, pero cambian el modelo económico. Un producto puede mostrar un comportamiento en frío excelente porque retiene más calor. Esa puede ser la compensación adecuada para aplicaciones interactivas, pero no debe separarse del coste de mantener esa ruta.
Líneas de Pareto de coste: dónde se cruzan los modelos de precios
Una hoja de precios no es suficiente. Un precio unitario bajo no ayuda si el producto no puede alcanzar el QPS objetivo. Una configuración de alto rendimiento no es atractiva si cuesta más que otro producto que satisface los mismos requisitos de latencia, recall y carga útil.
La vista de Pareto de costos combina límites de benchmark medidos con modelos de precios. Para la configuración de solo consultas de LAION 100M, cada línea de producto se detiene en el QPS máximo observado en el benchmark. Luego, el gráfico estima el costo operativo en niveles de QPS objetivo y marca las opciones Pareto-óptimas bajo esas restricciones medidas.
Figura 6. Costo frente a QPS sostenido para cargas de trabajo de solo consultas de LAION 100M. La vista de Pareto muestra dónde los precios serverless son más eficientes a bajo QPS y dónde las configuraciones aprovisionadas de Zilliz se vuelven más rentables a medida que aumenta la utilización.
En el modelo actual de solo consultas de LAION 100M, Turbopuffer tiene la ventaja con QPS sostenido muy bajo. El punto de cruce medido se sitúa en aproximadamente 8 QPS: por debajo de él, los precios de consulta medidos por uso de turbopuffer son la línea más barata; por encima de él, Zilliz Cloud Tiered 4CU se vuelve más barato, porque su costo de servicio por hora-CU es mayormente plano una vez aprovisionado. A medida que aumenta el QPS, la utilización mejora y la capacidad aprovisionada se vuelve más rentable.
Eso no significa que serverless sea peor. Significa que la economía de serverless y la de aprovisionamiento se cruzan. Para cargas de trabajo bajas, con picos o impredecibles, serverless medido por uso puede ser la mejor opción. Para tráfico de producción sostenido, un modelo plano por hora-CU puede volverse más barato una vez que la utilización supera el punto de cruce. Para equipos que necesitan envolventes de servicio más sólidas, comportamiento en frío o control operativo, Zilliz Capacity puede ser el perfil adecuado incluso cuando Tiered es la línea de menor costo.
Zilliz Cloud vs. Turbopuffer vs. Pinecone: Mejor ajuste por carga de trabajo
| Forma de la carga de trabajo | Señal más fuerte | Por qué |
|---|---|---|
| QPS sostenido muy bajo | turbopuffer | La economía serverless medida por uso es atractiva antes del cruce de bajo QPS |
| QPS sostenido por encima del cruce (~8 QPS en este modelo) | Zilliz Cloud Tiered | La economía plana por hora-CU mejora a medida que aumenta la utilización |
| Datos recientes o actualización frecuente | Zilliz Cloud Capacity / Tiered | La preparación de inserción a búsqueda y de indexación completa es sólida en el caso de inserción de LAION 100M |
| Sensibilidad al costo de carga completa grande | Zilliz Cloud Capacity / Tiered | El costo del lado de escritura es mucho menor en la ruta de carga masiva de LAION 100M probada |
| Búsqueda amplia de payload sin filtrar | Turbopuffer y Zilliz Capacity 32CU | Turbopuffer es fuerte en recuperación amplia; Zilliz escala con más capacidad |
| Filtros selectivos o búsqueda con permisos | Zilliz Cloud Capacity / Tiered | Zilliz muestra QPS mucho más alto y menor latencia P99 en el punto de estrés de filtro del 99,9% |
| Muchos tenants ligeros | turbopuffer | El QPS bruto más fuerte en el extracto de 1.000 tenants |
| Aplicaciones interactivas sensibles al arranque en frío | Zilliz Cloud Capacity; Turbopuffer pinned | Ambos reducen las penalizaciones de la primera consulta, con diferentes modelos de costo |
| Línea base serverless de baja operación | Pinecone Serverless | Punto de referencia serverless maduro, incluso cuando no está en la frontera en esta carga de trabajo |
Cómo usar estos resultados de benchmarking
VDBBench y su Cost Leaderboard están diseñados para hacer que la evaluación de bases de datos vectoriales refleje más de cerca cómo los equipos compran y operan realmente productos cloud gestionados. El QPS máximo sigue importando, pero ya no es suficiente por sí solo. La pregunta más útil es si un producto puede cumplir simultáneamente los requisitos de latencia, recall, frescura, payload, tenancy y costo de la carga de trabajo.
Un flujo de evaluación práctico se ve así:
- Usa el Performance Leaderboard para comprender la capacidad de servicio bruta bajo condiciones de benchmark controladas.
- Usa el Cost Leaderboard para comprender las compensaciones entre costo y rendimiento en productos cloud gestionados y formas de carga de trabajo.
- Usa VDBBench en sí para reproducir los casos, probar otros productos o ejecutar el benchmark con datos y distribuciones de consultas similares a producción.
Los resultados actuales deben leerse con varias salvedades.
- Los productos se evaluaron el 10 de mayo de 2026, y el modelo de costos utiliza los precios de AWS us-west-2 vigentes en esa fecha. Los precios pueden cambiar según la fecha y la región.
- Las opciones de configuración, como modos fijados, capacidad aprovisionada, controles de escalado y limitación serverless, pueden afectar los resultados.
- Los estados de preparación no siempre se exponen de la misma manera, por lo que las definiciones de insertado, searchable y completamente indexado deben verificarse para cada cliente.
- Por último, las cargas de trabajo son específicas por diseño. Los resultados de Pareto de costos siempre deben leerse junto con la latencia, el recall, la forma del payload y los límites de servicio medidos.
Evalúe sus propias cargas de trabajo
El Cost Leaderboard es una instantánea pública de los resultados actuales, pero el cambio más importante está en el propio VDBBench. Ahora permite a los equipos evaluar el rendimiento y el costo juntos frente a restricciones específicas de la carga de trabajo: frescura, tamaño del payload, forma del tenant, comportamiento en frío y modelo operativo.
Un producto serverless puede ser una buena opción para QPS sostenidas bajas. La capacidad aprovisionada puede volverse más rentable cuando aumenta la utilización. Un sistema puede liderar en recuperación amplia, mientras que otro puede tener un mejor rendimiento con filtros selectivos, actualizaciones frecuentes o cargas de trabajo sensibles al arranque en frío.
El objetivo no es la mejor cifra de titular. Es el mejor ajuste para su carga de trabajo.
- Ver los resultados actuales: VDBBench Cost Leaderboard
- Reproduzca estos casos, o evalúe sus propios candidatos: VectorDBBench en GitHub
- ¿Preguntas o resultados para compartir? Abra un issue en GitHub o únase a la conversación en Discord
Sigue leyendo
Zilliz Cloud Just Landed in Claude Code
The Zilliz Cloud Plugin brings the full power of Zilliz Cloud directly into your Claude Code terminal as natural-language conversations.
Democratizing AI: Making Vector Search Powerful and Affordable
Zilliz democratizes AI vector search with Milvus 2.6 and Zilliz Cloud for powerful, affordable scalability, cutting costs in infrastructure, operations, and development.
AI Agents Are Quietly Transforming E-Commerce — Here’s How
Discover how AI agents transform e-commerce with autonomous decision-making, enhanced product discovery, and vector search capabilities for today's retailers.