“RIP, vector database” é o tipo de título que parece anunciar o enterro de uma categoria inteira. A história é mais interessante e bem menos definitiva. A turbopuffer, que nasceu como banco vetorial serverless, está redesenhando o próprio armazenamento para que o índice de vizinhos mais próximos deixe de ser a estrutura principal dos documentos.
O índice ANN continuará existindo e respondendo buscas por similaridade. A diferença é que ele vira um índice secundário, ao lado da busca textual, dos filtros e das demais formas de consulta. Essa mudança ajuda a entender um problema recorrente: quando uma solução criada para vetores passa a atender documentos completos, agregações e busca híbrida, a primeira decisão arquitetural pode começar a cobrar juros.
Por que o vetor virou a chave de tudo
Na primeira versão da turbopuffer, cada documento era basicamente um identificador e um vetor. O serviço usava armazenamento de objetos como fonte de verdade, com caches em NVMe e memória para entregar as consultas. Para localizar vetores semelhantes, adotou índices baseados em agrupamentos hierárquicos, primeiro SPANN e depois SPFresh, este último capaz de lidar melhor com atualizações incrementais.
Cada vetor recebia um endereço derivado do cluster e de sua posição local. Como os outros dados do documento ficavam associados a esse endereço, o índice ANN funcionava na prática como índice primário. Para um produto dedicado quase exclusivamente à busca vetorial, a escolha era coerente: o layout físico estava alinhado à consulta mais importante.
O produto cresceu. Vieram filtros por atributos, busca textual com BM25, regex, busca aproximada, vetores esparsos, ordenação e agregações. A turbopuffer passou a ser usada até em cenários que não têm a similaridade vetorial como operação central. O índice que ajudou a versão inicial começou a limitar os outros planos de consulta.
O preço de guardar o documento no endereço do vetor
A empresa aponta três problemas principais: amplificação de armazenamento, amplificação de escrita e blocos pequenos demais para algumas consultas.
Armazenamento duplicado
Um documento simples pode ter um vetor e uma cópia de seus atributos. Técnicas mais novas, como representações com múltiplos vetores por documento, quebram essa conta. Se cada vetor carrega o documento junto de seu endereço ANN, os mesmos atributos acabam repetidos várias vezes. Quanto mais rica a representação, maior o custo de manter o layout centrado no vetor.
Escritas que movimentam dados demais
O SPFresh pode reorganizar vetores entre clusters para preservar a qualidade da busca. Quando o endereço ANN muda e todo o documento está preso a ele, uma atualização de vetor força a movimentação de atributos e referências dos outros índices. Uma alteração pequena desencadeia trabalho em várias estruturas.
O tamanho de bloco errado para cada consulta
Consultas modernas costumam processar valores em lotes para aproveitar cache de CPU e instruções SIMD. O tamanho ideal varia. A turbopuffer relata que seus clusters ANN funcionam bem com algo próximo de 100 a 200 documentos, enquanto outros mecanismos preferem lotes maiores. DuckDB, ClickHouse e índices textuais trabalham com granularidades próprias.
Quando todo plano precisa seguir os blocos do índice vetorial, agregações e varreduras ficam presas a uma divisão que não foi desenhada para elas. A empresa já havia separado as listas da busca textual desse layout e afirma ter obtido índice dez vezes menor e consultas até vinte vezes mais rápidas. São números publicados pela própria fornecedora, não um benchmark independente, mas ajudam a mostrar a origem da mudança.
O que muda na versão 3
Na nova arquitetura, o documento recebe um identificador interno estável. Os índices secundários apontam para esse documento em vez de usar a posição atual do vetor como endereço principal. O ANN passa a ser apenas um desses índices. Reorganizar clusters deixa de exigir que todos os outros dados acompanhem fisicamente o movimento.
Essa indirection adiciona uma etapa para recuperar o documento depois de encontrar o vetor. Em troca, cada índice pode escolher o layout e o tamanho de bloco mais adequados à sua consulta. É uma troca conhecida em bancos de dados: evitar que a organização ideal para um acesso dite o formato de todos os outros.
A turbopuffer informa que a versão 3 já passa por toda a suíte de integração contínua, mas ainda está no trabalho de desempenho e paridade antes da produção. Portanto, a direção arquitetural foi anunciada; os resultados finais ainda precisam aparecer nos benchmarks e no uso real.
Isso significa que bancos vetoriais morreram?
Não. A mudança parte de uma empresa de busca vetorial e mantém ANN como recurso de primeira classe. O que está enfraquecendo é a ideia de que o vetor precisa ocupar o centro de qualquer sistema de recuperação para IA.
Aplicações RAG raramente procuram apenas “os documentos mais parecidos”. Elas filtram tenant e permissões, combinam termos exatos com similaridade semântica, ordenam por data, removem versões antigas e aplicam regras de negócio. Nesse contexto, full-text search, metadados, ACLs e agregações não são detalhes ao redor do vetor. Eles participam da mesma consulta.
Também existe um custo operacional em manter um banco transacional e um banco vetorial separados. Os dados precisam ser sincronizados, atualizações podem chegar fora de ordem e exclusões precisam alcançar os dois lados. PostgreSQL com extensões vetoriais, mecanismos de busca e bancos analíticos passaram a incorporar similaridade justamente para reduzir essa fragmentação em vários projetos.
Quando um serviço especializado ainda pode valer a pena
- o volume vetorial é grande demais para a infraestrutura já existente;
- latência, recall e custo de indexação foram medidos e justificam uma camada dedicada;
- a equipe precisa de recursos específicos de busca híbrida que o banco principal não entrega;
- o sistema aceita a complexidade de sincronização porque o índice pode ser reconstruído;
- a operação do serviço gerenciado é mais barata que manter essa capacidade internamente.
Para projetos menores, começar no banco que já guarda os documentos costuma ser a opção mais simples. Só vale separar quando os limites aparecem em métricas e perfis de consulta, não porque “todo RAG precisa de um vector database” virou parte do diagrama padrão.
O “RIP” do título funciona como provocação. A lição técnica é mais útil: um índice excelente para uma consulta pode ser uma péssima fundação para todas as outras. Vetores continuam vivos; a arquitetura centrada exclusivamente neles é que está sendo obrigada a dividir espaço.