O Amazon S3 Vectors Vai Matar os Bancos de Dados Vetoriais — ou Salvá-los?
Há pouco tempo, a AWS lançou algo novo: S3 Vectors. É a primeira tentativa deles de oferecer uma solução de armazenamento vetorial, permitindo armazenar e consultar embeddings vetoriais para busca semântica diretamente dentro do Amazon S3.
À primeira vista, parece um banco de dados vetorial leve rodando sobre armazenamento de objetos de baixo custo — a um preço claramente atraente em comparação com muitas soluções dedicadas de bancos de dados vetoriais.
amazon s3 vectors.png
Naturalmente, isso gerou muitas opiniões fortes. Vi pessoas nas redes sociais e em círculos de engenharia dizendo que isso poderia ser o fim dos bancos de dados vetoriais criados especificamente para esse fim — incluindo Milvus, Pinecone, Qdrant e outros. Uma afirmação ousada, certo?
Como arquiteto de engenharia do Milvus e alguém que passou muitas madrugadas pensando em busca vetorial, tenho que admitir que: S3 Vectors traz, sim, algo interessante para a mesa, especialmente em torno de custo e integração dentro do ecossistema AWS. Mas, em vez de “matar” os bancos de dados vetoriais, eu o vejo se encaixando no ecossistema como uma peça complementar. Na verdade, seu futuro real provavelmente está em trabalhar com bancos de dados vetoriais profissionais, não em substituí-los.
Neste post, vou explicar por que penso assim — analisando por três ângulos: a tecnologia em si, o que ela pode e não pode fazer, e o que isso significa para o mercado.
Um fato surpreendente: o armazenamento vetorial pode custar mais do que chamadas a LLMs
A busca vetorial é poderosa, mas vem com uma pegadinha séria: é cara. As demandas computacionais costumam ser uma a duas ordens de magnitude maiores do que você veria em um banco de dados NoSQL típico. Essa diferença não é apenas teórica — ela aparece em contas reais.
Recentemente conversei com o CTO de um popular app de anotações com IA, que me contou algo surpreendente: eles gastam o dobro do valor com busca vetorial em comparação com chamadas à API da OpenAI. Pense nisso por um segundo. Executar a camada de recuperação custa mais para eles do que pagar pelo próprio LLM. Isso vira de cabeça para baixo a suposição habitual.
O boom do ChatGPT em 2022 só tornou isso mais evidente. De repente, embeddings estavam em toda parte, e dados vetoriais se tornaram o tipo de dado que mais cresce na nuvem pública. Geração Aumentada por Recuperação (RAG) foi o motor — e, com ela, vieram três desafios que remodelaram o que um banco de dados vetorial como o Milvus precisava fazer:
Explosão massiva de dados: As cargas de trabalho saltaram de dezenas de milhões para dezenas de bilhões de vetores quase da noite para o dia. Isso não é crescimento linear — é um salto quântico, e quebrou as formas antigas de lidar com dados.
A tolerância à latência mudou: Como os LLMs já levam tempo para gerar respostas, os usuários passaram a ser mais tolerantes com uma recuperação ligeiramente mais lenta. A mentalidade de “recall abaixo de 10 ms a qualquer custo” de repente passou a importar menos.
A sensibilidade a custo disparou: Dobrar ou triplicar o volume de dados não era apenas um problema de armazenamento; tornou-se uma crise financeira se você tentasse escalar usando designs tradicionais pesados em computação.
Em resumo: os bancos de dados vetoriais tiveram que evoluir rápido, não porque a tecnologia não funcionasse, mas porque a economia da recuperação de repente passou a estar no centro das atenções.
A evolução do armazenamento vetorial: da memória ao disco, e agora ao armazenamento de objetos
A pressão em torno de custo e escala levou a uma conclusão: bancos de dados vetoriais não poderiam permanecer apenas em memória para sempre. Eles precisavam evoluir — primeiro para disco, e agora para armazenamento de objetos como S3. Isso não foi uma escolha; foi uma inevitabilidade da indústria. E, se você tem acompanhado esse espaço, provavelmente notou a mesma tendência que eu nos últimos anos.
Vi bancos de dados vetoriais passarem por três estágios distintos:
Fase I (2018–2022): A Era da Memória Pura: Nos primeiros dias do Milvus, nós nos apoiávamos em índices em memória como HNSW e IVF. O desempenho e o recall eram fantásticos — mas os custos eram brutais. Memória não escala de forma barata, e todos que pagavam aquelas contas de nuvem sabiam disso.
Fase II (2022–2024): A Revolução dos Índices em Disco: Para romper o gargalo da memória, fomos pioneiros em uma abordagem baseada em disco usando DiskANN junto com nosso índice proprietário Cardinal (exclusivo do Zilliz Cloud, o Milvus gerenciado). Com truques como I/O assíncrono (AIO) e io_uring, conseguimos extrair desempenho real dos discos. O resultado? Uma redução de custos de 3 a 5x. Nossas unidades de computação (CUs) otimizadas para capacidade rapidamente se tornaram campeãs de vendas no Zilliz Cloud.
Fase III (2024– ): A Era do Armazenamento em Camadas: O próximo passo era óbvio: levar índices vetoriais para armazenamento de objetos barato. Novos players como TurboPuffer apostaram tudo no S3, reduzindo os custos de armazenamento para ~$0,33/GB/mês — uma redução de 10x. Mas a contrapartida era igualmente clara: latência de consultas frias na faixa de 500 ms a 1 s, e precisão de recall mais fraca.
Na Zilliz, estamos trabalhando em armazenamento em camadas há algum tempo, mas adiamos o lançamento até conseguirmos controlar o desempenho de consultas frias. No próximo mês, lançaremos nossas CUs de capacidade estendida atualizadas com separação real entre quente/frio no Zilliz Cloud. Isso significa latência estável de consultas frias abaixo de 500 ms, combinada com QPS ultra-alto para consultas quentes. Em outras palavras, o melhor dos dois mundos.
Amazon S3 Vectors Chega na Hora Certa
Com o armazenamento em camadas já provando seu valor, não surpreende que a AWS tenha entrado em cena com S3 Vectors. Na verdade, o lançamento parece uma extensão natural do que já vinha acontecendo em todo o setor. A Amazon vinha expandindo o papel do S3 com recursos como S3 Tables, evoluindo-o de “apenas armazenamento de objetos” para uma espinha dorsal de armazenamento frio multimodal. Vetores são simplesmente a próxima modalidade nessa evolução — e provavelmente não vai parar por aí. Grafos, chave-valor e dados de séries temporais poderiam seguir o mesmo caminho.
E a Amazon traz três vantagens inegáveis para a mesa:
Custo mais baixo: entre os menores preços de armazenamento do setor.
Escala massiva: os pools de máquinas da AWS conseguem absorver praticamente qualquer carga de consultas.
Arquitetura nativa de microsserviços: perfeitamente alinhada ao fluxo de trabalho de escrita–construção–consulta da indexação vetorial.
Somadas, essas vantagens dão ao S3 Vectors os ingredientes para se tornar uma solução de armazenamento frio de custo ultrabaixo e altamente escalável para vetores.
S3 Vectors é um Verdadeiro Matador de Preços, Mas Com Limites Claros
Assim que o S3 Vectors foi anunciado, nossa equipe o submeteu a testes abrangentes. Os resultados foram reveladores — não apenas em termos de quão barato ele é, mas também de onde as rachaduras começam a aparecer.
S3 Vectors é um Verdadeiro Matador de Preços
Não há como negar: S3 Vectors é incrivelmente econômico.
O armazenamento custa apenas $0,06/GB, cerca de 5 vezes mais barato do que a maioria das soluções vetoriais serverless. Para uma carga de trabalho representativa — digamos, 400 milhões de vetores mais 10 milhões de consultas por mês — a conta fica em cerca de $1.217/mês. Isso representa uma redução de mais de 10x em comparação com bancos de dados vetoriais tradicionais. Para cargas de trabalho de baixo QPS e tolerantes à latência, é quase imbatível.
Mas o Desempenho Tem Restrições Reais
Limites de tamanho da coleção: Cada tabela S3 chega ao máximo de 50M de vetores, e você só pode criar até 10.000 tabelas.
Consultas frias: A latência fica em ~500ms para 1M de vetores e ~700ms para 10M de vetores.
Consultas quentes: A latência permanece abaixo de 200ms a 200 QPS, mas ir além desse teto de 200 QPS é difícil.
Desempenho de escrita: Limitado a menos de 2MB/s. Isso é ordens de magnitude menor que o Milvus (que lida com GB/s), embora, a seu favor, as escritas não degradem o desempenho das consultas. Tradução: ele não foi projetado para cenários com conjuntos de dados grandes e que mudam com frequência.
Compromissos de Precisão e Funcionalidade
A questão da precisão é onde as coisas ficam complicadas. O recall fica em torno de 85–90%, e você não tem controles para ajustá-lo para mais alto. Adicione filtros, e o recall pode cair abaixo de 50%. Em um teste em que excluímos 50% dos dados, consultas TopK solicitaram 20 resultados, mas só conseguiram retornar 15.
A funcionalidade também é reduzida. Consultas TopK chegam ao máximo de 30. Metadados por registro têm limites rígidos de tamanho. E você não encontrará recursos como busca híbrida, multi-tenancy ou filtragem avançada — todos eles indispensáveis para muitas aplicações de produção.
Dissecando o S3 Vectors: A Arquitetura Provável
Depois de executar testes e mapeá-los contra padrões de design familiares da AWS, formamos uma hipótese bastante boa de como o S3 Vectors funciona por baixo dos panos. Embora a Amazon não tenha publicado todos os detalhes, as características de desempenho apontam para cinco tecnologias centrais:
Indexação Dinâmica SPFresh: Em vez de reconstruir índices inteiros após cada escrita, o S3 Vectors parece atualizar apenas as partes afetadas. Esse design mantém os custos de escrita baixos e a disponibilidade alta, mas tem um preço: as taxas de recall caem alguns pontos percentuais após as atualizações.
Quantização Profunda (PQ de 4 bits): Para reduzir a sobrecarga de I/O do S3, os embeddings provavelmente são comprimidos usando quantização de produto de 4 bits.
O lado positivo: o armazenamento é barato, e as consultas permanecem rápidas.
O lado negativo: o recall estaciona em torno de ~85%, e não há controles para os desenvolvedores ajustá-lo para mais alto.
Mecanismo de Pós-Filtro: A filtragem parece ser aplicada após a recuperação grosseira. Isso mantém o índice unificado e simples, mas ele tem dificuldade com condições complexas. Em nossos testes, quando excluímos 50% dos dados, consultas TopK solicitando 20 resultados retornaram apenas 15 — sinais clássicos de um pipeline de pós-filtro. Isso também sugere que a Amazon se apoiou fortemente em designs de índices open-source existentes, em vez de construir um personalizado do zero.
Cache em Múltiplas Camadas: Consultas quentes se comportam muito mais rápido, provavelmente graças a um cache SSD/NVMe à frente do S3. Mas quando uma consulta não acerta o cache, a latência salta significativamente. Esse padrão se encaixa em uma hierarquia de cache em múltiplas camadas criada para mascarar a lentidão inerente do armazenamento de objetos.
Agendamento Distribuído em Larga Escala: A AWS não tem falta de pools de máquinas. O S3 Vectors parece espalhar a carga de trabalho por microserviços, encadeando em pipeline o fluxo leitura → descompressão → busca. O resultado é o que observamos nos testes: uma distribuição de latência notavelmente estável, mesmo sob carga pesada.
Onde o S3 Vectors se Encaixa: A Ferramenta Certa para Trabalhos Específicos
Depois de colocar o S3 Vectors à prova, fica claro que ele brilha em alguns cenários e fica aquém em outros. Como a maioria das ferramentas de infraestrutura, não é uma solução única para tudo — é a ferramenta certa para o trabalho certo.
Onde Funciona Bem
Arquivamento de dados frios: Perfeito para armazenar conjuntos de dados históricos que raramente são acessados. Se você consegue conviver com tempos de consulta de 500ms+, a economia de custos é imbatível.
Consultas RAG de baixo QPS: Pense em pequenas ferramentas internas ou chatbots que executam apenas dezenas de consultas por dia, permanecendo abaixo de 100 QPS. Para esses casos de uso, a latência não é um fator impeditivo.
Prototipagem de baixo custo: Ótimo para projetos de prova de conceito em que o objetivo é testar uma ideia sem gastar muito com infraestrutura.
Onde Tem Dificuldade
Busca e recomendação de alto desempenho: Se sua aplicação precisa de latência abaixo de 50 ms, o S3 Vectors simplesmente não foi feito para isso.
Gravações de alto volume ou atualizações frequentes: O desempenho degrada rapidamente, e a precisão de recall cai visivelmente sob alta rotatividade.
Cargas de trabalho de consultas complexas: Não há suporte para busca híbrida, agregações ou outros recursos avançados de consulta.
Apps de produção multi-tenant: Com um limite rígido de 10.000 buckets, ele não foi projetado para implantações multi-tenant em larga escala.
Em outras palavras, o S3 Vectors é excelente para cenários frios, baratos e de baixo QPS — mas não é o mecanismo que você quer para impulsionar um sistema de recomendação, um app de busca em tempo real ou qualquer sistema de produção em alta escala.
O futuro é o armazenamento vetorial em camadas
O S3 Vectors não significa o fim dos bancos de dados vetoriais — ele confirma algo que muitos de nós já vínhamos observando há algum tempo: o futuro é o armazenamento em camadas. Em vez de manter todos os vetores em memória cara ou em disco rápido, as cargas de trabalho naturalmente se distribuirão entre camadas quentes, mornas e frias com base na frequência de acesso e no tipo de latência que a aplicação pode tolerar.
Veja como isso funciona na prática:
Camada de dados quentes (<50 ms) – É aqui que vivem a busca em tempo real, as recomendações e os anúncios direcionados. A latência precisa ficar abaixo de 50 ms, o que significa que bancos de dados vetoriais especializados ainda são a melhor opção. Eles são otimizados tanto para velocidade altíssima quanto para alto throughput de consultas.
Camada de dados mornos (50–500 ms) – Muitas aplicações baseadas em RAG e serviços compartilhados multi-tenant se enquadram aqui. Essas cargas de trabalho não precisam de latência ultrabaixa, mas precisam de desempenho previsível a um custo menor. O S3 Vectors e as instâncias de armazenamento em camadas do Milvus se encaixam nesse meio-termo.
Camada de dados frios (>500 ms) – Arquivos históricos e análises offline não exigem respostas em tempo real, então latência na casa das centenas de milissegundos é aceitável. O que importa aqui é eficiência de custo em escala massiva. É aqui que soluções como S3 + Spark/Daft ou o data lake vetorial do Milvus se destacam.
A divisão quente–morna–fria equilibra latência, custo e escala de uma forma que nenhuma camada de armazenamento única consegue cobrir sozinha. É um padrão que já vimos antes em bancos de dados relacionais, data warehouses e até CDNs — e o armazenamento vetorial agora segue a mesma trajetória. Essa arquitetura de três camadas também se alinha de perto com o roadmap que estamos construindo para o Milvus e o Zilliz Cloud.
1. Uma arquitetura unificada de processamento online + offline
Aplicações de IA não vivem perfeitamente separadas em mundos “online” e “offline”. Na realidade, os dados se movem constantemente entre os dois. É por isso que, com o próximo Milvus 3.0, vamos introduzir um data lake vetorial, projetado para oferecer suporte tanto à recuperação em tempo real quanto ao processamento offline a partir do mesmo conjunto de dados.
Na prática, isso significa que um único conjunto de dados pode alimentar suas consultas RAG e de busca ao vivo, ao mesmo tempo em que também alimenta análises offline baseadas em Spark — por exemplo, curando dados de treinamento para LLMs. Sem duplicação, sem gerenciar dois pipelines diferentes.
Também lançaremos o formato StorageV2 para o data lake vetorial, que leva a economia a outro nível:
Até 100x mais barato para armazenamento de dados frios.
Até 100x mais rápido do que consultas Spark por força bruta em dados quentes.
O resultado é um sistema unificado que minimiza a redundância, mantém os custos sob controle e torna o trabalho com dados vetoriais muito menos doloroso.
2. Criando recursos de que desenvolvedores de IA realmente precisam
Nos últimos dois anos, as aplicações de IA vêm avançando rapidamente — e os requisitos para a infraestrutura por trás delas também. Na Zilliz, impulsionamos o Milvus em sintonia com essas necessidades, lançando recursos como busca híbrida BM25 + vetorial, isolamento multi-tenant, armazenamento em camadas quente–frio e deduplicação com MinHash, junto com uma longa lista de melhorias focadas em desenvolvedores.
Nossa filosofia tem sido simples: quando você combina um entendimento profundo dos casos de uso de negócio com a tecnologia mais recente, desbloqueia possibilidades de infraestrutura totalmente novas. Essa é a mentalidade que molda o Milvus 3.0, que trará uma nova onda de recursos nativos de IA projetados diretamente para aplicações do mundo real. Entre eles:
Ponderação de palavras-chave na busca – Para que uma consulta como “telefone vermelho” possa priorizar vermelho adequadamente.
Suporte a geolocalização – Armazene e consulte vetores com consciência de localização para lidar com prompts como “encontre cafeterias próximas.”
Suporte a múltiplos vetores para RAG – Anexe múltiplos embeddings a cada texto, melhorando a recuperação e a precisão em tarefas complexas de recuperação.
Processamento flexível com UDF – Funções definidas pelo usuário para um processamento de dados mais rico e personalizável.
Ferramentas de análise visual – Mineração offline mais profunda e exploração de dados em escala.
E isso é só o começo. O ponto mais importante é que o Milvus está evoluindo para um sistema que não é apenas eficiente e escalável, mas nativo de IA em sua essência — construído especificamente para a forma como as aplicações modernas realmente funcionam.
3. Engenharia para Escala Sem o Alto Custo
Na Zilliz, acreditamos que: uma redução de custo de 10x abre a porta para 100x mais casos de uso de aplicações. Esse princípio guiou todos os grandes marcos do Milvus. Desde 2022, introduzimos índices baseados em disco, aceleração por GPU e quantização RabitQ — todos elevando o desempenho de consultas em ordens de magnitude enquanto reduzem custos.
Olhando para o futuro, nosso foco está em extrair ainda mais eficiência da stack:
Otimização de hardware mais profunda – Ajustes para potência de computação bruta e desempenho de IOPS.
Compressão e quantização mais inteligentes – Tornando os vetores mais leves sem abrir mão da precisão.
Encerramento antecipado para consultas de índice – Cortando computação desperdiçada assim que tivermos resultados confiáveis.
Indexação em camadas refinada – Melhor utilização de cache para acesso mais rápido a dados frios.
O objetivo final não mudou: construir uma infraestrutura que simplesmente funcione pronta para uso, escale sob demanda e permaneça rápida e acessível.
Por Que o Advento do S3 Vectors É uma Boa Notícia para Todos
Muita gente se preocupa que o S3 Vectors torne os bancos de dados vetoriais tradicionais obsoletos. Minha visão é o oposto: seu lançamento é uma boa notícia para toda a indústria. Na verdade, vejo três grandes benefícios.
Isso valida a demanda. Ninguém pode mais afirmar que vetores são apenas uma moda passageira. Se a AWS está criando um produto em torno disso, é uma prova concreta de que o armazenamento vetorial é uma necessidade real — não apenas “índices embrulhados em um banco de dados.”
Isso educa o mercado. Com o alcance da AWS, mais empresas agora estão cientes dos bancos de dados vetoriais, o que expande os limites do que pode ser construído em aplicações.
Isso impulsiona a inovação. A concorrência força todos nós — incluindo o Milvus — a otimizar mais, reduzir custos ainda mais e encontrar forças diferenciadas.
Do ponto de vista de posicionamento, o S3 Vectors parece menos um banco de dados vetorial completo e mais a camada fria de armazenamento vetorial. Seu baixo custo o torna especialmente atraente para cenários que antes eram inviáveis por preço: pequenas equipes criando apps RAG, desenvolvedores individuais fazendo experimentos ou organizações indexando conjuntos de dados massivos com apenas necessidades básicas de recuperação. Isso é um verdadeiro desbloqueio para o ecossistema.
Pessoalmente, também quero reconhecer a equipe de engenharia da AWS. Eles vêm melhorando continuamente sua plataforma — da depuração no Lambda ao desempenho de cold start — e o S3 Vectors é outro exemplo de inovação de produto bem pensada. Estou genuinamente curioso para ver o que os desenvolvedores vão construir agora que a economia está tão favorável.
Então não, o mercado de bancos de dados vetoriais não está sendo disruptado — ele está amadurecendo para um ecossistema em camadas, onde diferentes soluções atendem a diferentes necessidades de desempenho e custo. Isso é bom para empresas, bom para desenvolvedores e bom para toda a stack de infraestrutura de IA.
A era de ouro dos bancos de dados vetoriais não acabou — está apenas começando.
Continue lendo
Zilliz Cloud Launches in AWS Australia, Expanding Global Reach to Australia and Neighboring Markets
We're thrilled to announce that Zilliz Cloud is now available in the AWS Sydney, Australia region (ap-southeast-2).
Cosmos World Foundation Model Platform for Physical AI
NVIDIA's Cosmos platform enables safe, digital twin training of GenAI models for physical applications, overcoming data scarcity and safety challenges.
Introducing DeepSearcher: A Local Open Source Deep Research
In contrast to OpenAI’s Deep Research, this example ran locally, using only open-source models and tools like Milvus and LangChain.