Anunciando o VDBBench 1.0: Benchmarking de VectorDB de código aberto com suas cargas de trabalho de produção do mundo real
A maioria dos benchmarks de bancos de dados vetoriais testa com dados estáticos e índices pré-construídos. Mas sistemas em produção não funcionam assim—os dados fluem continuamente enquanto os usuários executam consultas, filtros fragmentam índices, e as características de desempenho mudam drasticamente sob cargas simultâneas de leitura/gravação.
Hoje estamos lançando o VDBBench 1.0, um benchmark open-source projetado desde o início para testar bancos de dados vetoriais sob condições realistas de produção: ingestão de dados em streaming, filtragem de metadados com seletividade variável e cargas de trabalho concorrentes que revelam gargalos reais do sistema.
Baixe o VDBBench 1.0 → | Veja o Leaderboard →
Por que os benchmarks atuais são enganosos
Sejamos honestos—há um fenômeno estranho em nosso setor. Todos falam sobre "não manipular benchmarks", mas muitos participam exatamente desse comportamento. Desde que o mercado de bancos de dados vetoriais explodiu em 2023, vimos inúmeros exemplos de sistemas que "se saem maravilhosamente em benchmarks", mas "fracassam miseravelmente" em produção, desperdiçando tempo de engenharia e prejudicando a credibilidade dos projetos.
Testemunhamos essa desconexão em primeira mão. Por exemplo, o Elasticsearch ostenta velocidades de consulta na casa dos milissegundos, mas, nos bastidores, pode levar mais de 20 horas apenas para otimizar seu índice. Que sistema de produção pode tolerar esse tipo de indisponibilidade?
O problema decorre de três falhas fundamentais:
Datasets desatualizados: Muitos benchmarks ainda dependem de datasets legados como SIFT (128 dimensões), enquanto embeddings modernos variam de 768 a 3.072 dimensões. As características de desempenho de sistemas operando em vetores 128D versus 1024D+ são fundamentalmente diferentes—padrões de acesso à memória, eficiência do índice e complexidade computacional mudam drasticamente.
Métricas de vaidade: Benchmarks se concentram em latência média ou QPS de pico, criando uma imagem distorcida. Um sistema com latência média de 10 ms, mas latência P99 de 2 segundos, cria uma experiência de usuário terrível. O throughput de pico medido ao longo de 30 segundos não diz nada sobre desempenho sustentado.
Cenários simplificados demais: A maioria dos benchmarks testa fluxos de trabalho básicos de "gravar dados, construir índice, consultar"—essencialmente testes no nível de "Hello World". A produção real envolve ingestão contínua de dados enquanto atende consultas, filtragem complexa de metadados que fragmenta índices e operações concorrentes de leitura/gravação competindo por recursos.
O que há de novo no VDBBench 1.0?
O VDBBench não apenas itera sobre filosofias de benchmarking desatualizadas—ele reconstrói o conceito a partir de princípios fundamentais com uma crença orientadora: um benchmark só é valioso se prever o comportamento real em produção.
Projetamos o VDBBench para replicar fielmente condições do mundo real em três dimensões críticas: autenticidade dos dados, padrões de carga de trabalho e metodologias de medição de desempenho.
Vamos dar uma olhada mais de perto nos novos recursos que chegam agora.
🚀 Dashboard redesenhado com visualizações relevantes para produção
A maioria dos benchmarks se concentra apenas na saída de dados brutos, mas o que importa é como os engenheiros interpretam e agem com base nesses resultados. Redesenhamos a UI para priorizar clareza e interatividade—permitindo que você identifique lacunas de desempenho entre sistemas e tome decisões rápidas de infraestrutura.
O novo dashboard visualiza não apenas números de desempenho, mas as relações entre eles: como o QPS se degrada sob diferentes níveis de seletividade de filtro, como o recall flutua durante a ingestão em streaming e como as distribuições de latência revelam características de estabilidade do sistema.
Dashboard do VDBbench
Testamos novamente as principais plataformas de bancos de dados vetoriais, incluindo Milvus, Zilliz Cloud, Elastic Cloud, Qdrant Cloud, Pinecone e OpenSearch, com suas configurações mais recentes e definições recomendadas, garantindo que todos os dados de benchmark reflitam as capacidades atuais. Todos os resultados dos testes estão disponíveis no VDBBench Leaderboard.
🏷️ Filtragem por Tags: O Assassino Oculto de Desempenho
Consultas do mundo real raramente acontecem de forma isolada. As aplicações combinam similaridade vetorial com filtragem de metadados ("encontre sapatos parecidos com esta foto, mas que custem menos de US$100"). Essa busca vetorial filtrada cria desafios únicos que a maioria dos benchmarks ignora completamente.
Buscas filtradas introduzem complexidade em duas áreas críticas:
Complexidade do Filtro: Mais campos escalares e condições lógicas complexas aumentam as demandas computacionais e podem causar recall insuficiente e fragmentação do índice em grafo.
Seletividade do Filtro: Este é o "assassino oculto de desempenho" que verificamos repetidamente em produção. Quando as condições de filtragem se tornam altamente seletivas (filtrando mais de 99% dos dados), as velocidades de consulta podem flutuar em ordens de magnitude, e o recall pode se tornar instável à medida que as estruturas de índice têm dificuldade com conjuntos de resultados esparsos.
O VDBBench testa sistematicamente vários níveis de seletividade de filtragem (de 50% a 99,9%), fornecendo um perfil de desempenho abrangente sob esse padrão crítico de produção. Os resultados frequentemente revelam quedas dramáticas de desempenho que jamais apareceriam em benchmarks tradicionais.
Exemplo: Nos testes Cohere 1M, o Milvus manteve um recall consistentemente alto em todos os níveis de seletividade de filtro, enquanto o OpenSearch exibiu desempenho instável, com o recall flutuando significativamente sob diferentes condições de filtragem—caindo abaixo de 0,8 de recall em muitos casos, o que é inaceitável para a maioria dos ambientes de produção.
Figura: QPS e Recall do Milvus e do OpenSearch em Diferentes Níveis de Seletividade de Filtro (Teste Cohere 1M).
🌊 Leitura/Escrita em Streaming: Além dos Testes de Índices Estáticos
Sistemas de produção raramente desfrutam do luxo de dados estáticos. Novas informações fluem continuamente enquanto as buscas são executadas—um cenário em que muitos bancos de dados, de outro modo impressionantes, entram em colapso sob a dupla pressão de manter o desempenho de busca enquanto lidam com escritas contínuas.
Os cenários de streaming do VDBBench simulam operações paralelas reais, ajudando desenvolvedores a entender a estabilidade do sistema em ambientes de alta concorrência, particularmente como a escrita de dados impacta o desempenho das consultas e como o desempenho evolui à medida que o volume de dados aumenta.
Para garantir comparações justas entre diferentes sistemas, o VDBBench usa uma abordagem estruturada:
Configurar taxas de escrita controladas que espelham cargas de trabalho de produção-alvo (por exemplo, 500 linhas/s distribuídas por 5 processos paralelos)
Acionar operações de busca após cada 10% de ingestão de dados, alternando entre os modos serial e concorrente
Registrar métricas abrangentes: distribuições de latência (incluindo P99), QPS sustentado e precisão de recall
Acompanhar a evolução do desempenho ao longo do tempo conforme o volume de dados e o estresse do sistema aumentam
Esse teste de carga controlado e incremental revela quão bem os sistemas mantêm estabilidade e precisão sob ingestão contínua—algo que benchmarks tradicionais raramente capturam.
Exemplo: Nos testes de streaming Cohere 10M, o Pinecone manteve QPS e recall mais altos ao longo de todo o ciclo de escrita em comparação com o Elasticsearch. Notavelmente, o desempenho do Pinecone melhorou significativamente após a conclusão da ingestão, demonstrando forte estabilidade sob carga sustentada, enquanto o Elasticsearch apresentou um comportamento mais irregular durante as fases de ingestão ativa.
Figura: QPS e Recall do Pinecone vs. Elasticsearch no Teste de Streaming Cohere 10M (Taxa de Ingestão de 500 linhas/s).
O VDBBench vai ainda mais longe ao oferecer suporte a uma etapa opcional de otimização, permitindo que os usuários comparem o desempenho da busca em streaming antes e depois da otimização do índice. Ele também rastreia e relata o tempo real gasto em cada etapa, oferecendo insights mais profundos sobre a eficiência do sistema e seu comportamento em condições semelhantes às de produção.
Figura: QPS e Recall do Pinecone vs. Elasticsearch no Teste de Streaming Cohere 10M Após a Otimização (Taxa de Ingestão de 500 linhas/s)
Como mostrado em nossos testes, o Elasticsearch superou o Pinecone em QPS — após a otimização do índice. Mas quando o eixo x reflete o tempo decorrido real, fica claro que o Elasticsearch levou significativamente mais tempo para atingir esse desempenho. Em produção, esse atraso importa. Esta comparação revela uma troca fundamental: taxa de transferência máxima vs. tempo até estar pronto para servir.
🔬 Conjuntos de Dados Modernos Que Refletem Cargas de Trabalho Atuais de IA
Reformulamos completamente os conjuntos de dados usados para benchmarking de bancos de dados vetoriais. Em vez de conjuntos de teste legados como SIFT e GloVe, o VDBBench usa vetores gerados a partir de modelos de embedding de ponta, como OpenAI e Cohere, que impulsionam as aplicações de IA atuais.
Para garantir relevância, especialmente para casos de uso como Retrieval-Augmented Generation (RAG), selecionamos corpora que refletem cenários empresariais e específicos de domínio do mundo real:
| Corpus | Modelo de Embedding | Dimensões | Tamanho | Caso de Uso |
|---|---|---|---|---|
| Wikipedia | Cohere V2 | 768 | 1M / 10M | Base de conhecimento geral |
| BioASQ | Cohere V3 | 1024 | 1M / 10M | Específico de domínio (biomédico) |
| C4 | OpenAI | 1536 | 500K / 5M | Processamento de texto em escala web |
| MSMarco V2 | udever-bloom-1b1 | 1536 | 1M / 10M / 138M | Busca em larga escala |
Esses conjuntos de dados simulam melhor os dados vetoriais atuais de alto volume e alta dimensionalidade, permitindo testes realistas de eficiência de armazenamento, desempenho de consultas e precisão de recuperação em condições que correspondem às cargas de trabalho modernas de IA.
⚙️ Suporte a Conjuntos de Dados Personalizados para Testes Específicos da Indústria
Cada negócio é único. O setor financeiro pode precisar de testes focados em embeddings de transações, enquanto plataformas sociais se preocupam mais com vetores de comportamento de usuários. O VDBBench permite que você faça benchmarking com seus próprios dados gerados a partir dos seus modelos de embedding específicos para suas cargas de trabalho específicas.
Você pode personalizar:
Dimensões vetoriais e tipos de dados
Esquema de metadados e padrões de filtragem
Volume de dados e padrões de ingestão
Distribuições de consultas que correspondem ao seu tráfego de produção
Afinal, nenhum conjunto de dados conta uma história melhor do que seus próprios dados de produção.
Como o VDBBench Mede o Que Realmente Importa em Produção
Design de Métricas Focado em Produção
O VDBBench prioriza métricas que refletem o desempenho no mundo real, não apenas resultados de laboratório. Redesenhamos o benchmarking em torno do que realmente importa em ambientes de produção: confiabilidade sob carga, características de latência de cauda, taxa de transferência sustentada e preservação da precisão.
Latência P95/P99 para a Experiência Real do Usuário: A latência média/mediana mascara os outliers que frustram usuários reais e podem indicar instabilidade subjacente do sistema. O VDBBench se concentra na latência de cauda, como P95/P99, revelando qual desempenho 95% ou 99% das suas consultas realmente alcançarão. Isso é crucial para o planejamento de SLA e para entender a experiência do usuário no pior caso.
Taxa de Transferência Sustentável Sob Carga: Um sistema que funciona bem por 5 segundos não é suficiente em produção. O VDBBench aumenta gradualmente a concorrência para encontrar o máximo de consultas sustentáveis por segundo (
max_qps) do seu banco de dados — não o número máximo em condições curtas e ideais. Essa metodologia revela quão bem seu sistema se mantém ao longo do tempo e ajuda no planejamento realista de capacidade.Recall equilibrado com desempenho: Velocidade sem precisão não significa nada. Cada número de desempenho no VDBBench é acompanhado por medições de recall, para que você saiba exatamente quanta relevância está trocando por throughput. Isso permite comparações justas, de igual para igual, entre sistemas com tradeoffs internos muito diferentes.
Metodologia de teste que reflete a realidade
Uma inovação fundamental no design do VDBBench é a separação entre testes seriais e concorrentes, o que ajuda a capturar como os sistemas se comportam sob diferentes tipos de carga e revela características de desempenho que importam para diferentes casos de uso.
Separação da medição de latência:
serial_latency_p99mede o desempenho do sistema sob carga mínima, em que apenas uma solicitação é processada por vez. Isso representa o melhor cenário para latência e ajuda a identificar as capacidades básicas do sistema.conc_latency_p99captura o comportamento do sistema sob condições realistas de alta concorrência, em que várias solicitações chegam simultaneamente e competem pelos recursos do sistema.
Estrutura de benchmark em duas fases:
Teste serial: Execução em processo único de 1.000 consultas que estabelece desempenho e precisão de referência, reportando tanto
serial_latency_p99quanto recall. Esta fase ajuda a identificar o teto teórico de desempenho.Teste de concorrência: Simula um ambiente de produção sob carga sustentada com várias inovações importantes:
Simulação realista de clientes: Cada processo de teste opera de forma independente, com sua própria conexão e conjunto de consultas, evitando interferência de estado compartilhado que poderia distorcer os resultados
Início sincronizado: Todos os processos começam simultaneamente, garantindo que o QPS medido reflita com precisão os níveis de concorrência declarados
Conjuntos de consultas independentes: Evita taxas irreais de acerto em cache que não refletem a diversidade de consultas em produção
Esses métodos cuidadosamente estruturados garantem que os valores de max_qps e conc_latency_p99 relatados pelo VDBBench sejam precisos e relevantes para produção, fornecendo insights significativos para o planejamento de capacidade em produção e o design de sistemas.
Começando com o VDBBench 1.0
VDBBench 1.0 representa uma mudança fundamental rumo a benchmarks relevantes para produção. Ao abranger escrita contínua de dados, filtragem de metadados com seletividade variável e cargas de streaming sob padrões de acesso concorrente, ele fornece a aproximação mais próxima dos ambientes reais de produção disponível hoje.
A lacuna entre resultados de benchmark e desempenho no mundo real não deveria ser um jogo de adivinhação. Se você está planejando implantar um banco de dados vetorial em produção, vale a pena entender como ele se comporta além de testes de laboratório idealizados. O VDBBench é open-source, transparente e projetado para apoiar comparações significativas, de igual para igual.
Não se deixe influenciar por números impressionantes que não se traduzem em valor para produção. Use o VDBBench 1.0 para testar cenários que importam para o seu negócio, com seus dados, sob condições que reflitam sua carga de trabalho real. A era dos benchmarks enganosos na avaliação de bancos de dados vetoriais está terminando—é hora de tomar decisões com base em dados relevantes para produção.
Experimente o VDBBench com suas próprias cargas de trabalho: https://github.com/zilliztech/VectorDBBench
Veja os resultados de teste dos principais bancos de dados vetoriais: VDBBench Leaderboard
Tem perguntas ou quer compartilhar seus resultados? Participe da conversa no GitHub ou conecte-se com nossa comunidade no Discord.
Continue lendo
How Zilliz Ended Up at the Center of NVIDIA’s Unstructured Data Story at GTC 2026
If unstructured data is the context of AI, then the ceiling of AI applications will be set not just by models, but by how mature the infrastructure for unstructured data becomes.
Zilliz Cloud Delivers Better Performance and Lower Costs with Arm Neoverse-based AWS Graviton
Zilliz Cloud adopts Arm-based AWS Graviton3 CPUs to cut costs, speed up AI vector search, and power billion-scale RAG and semantic search workloads.
AI Integration in Video Surveillance Tools: Transforming the Industry with Vector Databases
Discover how AI and vector databases are revolutionizing video surveillance with real-time analysis, faster threat detection, and intelligent search capabilities for enhanced security.