A AWS disponibilizou a busca vetorial em geral no DynamoDB em 5 de agosto de 2026 — latência de milissegundos de um único dígito a 99%+ de recall, escalável para trilhões de vetores. As equipes que usam DynamoDB para cargas de trabalho transacionais agora podem armazenar embeddings na mesma tabela, criar um índice vetorial em qualquer atributo e executar consultas aproximadas de vizinho mais próximo através da nova API SearchVectors. Nenhum banco de dados de vetores separado. Nenhum pipeline de sincronização.

Um desenvolvedor gera embeddings com qualquer modelo — Bedrock Titan Text Embeddings V2, Cohere Embed, OpenAI — e os armazena como floats no item do DynamoDB. Depois cria um índice vetorial especificando o nome do atributo, contagem de dimensões e função de distância. O DynamoDB suporta até 4.096 dimensões e três funções de distância: Euclidean, Cosine, Dot product. SearchVectors retorna até 100 resultados classificados por score de similaridade, com dados do item retornados inline. Requisito do SDK: boto3/botocore ≥ 1.43.64.

A eliminação do pipeline de sincronização altera a economia da plataforma. Até agora, uma aplicação DynamoDB que precisava de busca semântica tinha que copiar dados para um armazenamento de vetores separado — Pinecone, Weaviate, OpenSearch — e executar um pipeline para manter os embeddings atualizados. Dois bancos de dados para monitorar. Custos de movimentação de dados. Uma superfície de falha entre caminhos de escrita e leitura. Os arquitetos da AWS Leonid Koren e Mo Kamioner enumeram o custo: complexidade de sincronização, uma rodada de ida e volta de rede extra para buscar dados do item após a busca vetorial, o custo de dois serviços gerenciados e dois modos de falha separados.

O faturamento fica em cima dos encargos padrão do DynamoDB: escritas no índice vetorial ($/GB), dados processados por busca ($/GB) e armazenamento ($/GB). A AWS recomenda reduzir custos usando modelos de dimensões inferiores, projetando apenas atributos necessários no índice, excluindo embeddings dos resultados de consultas e particionando o índice seletivamente. As taxas exatas por GB residem na página de preços do DynamoDB. As equipes devem comparar com os gastos atuais do Pinecone ou OpenSearch. A consolidação nem sempre economiza dinheiro.

As condições de filtro no momento da consulta são limitadas a predicados de correspondência exata em atributos não-vetoriais — não consultas de intervalo, não operadores de desigualdade. As equipes que precisam de "retornar resultados onde preço < $100" junto com similaridade vetorial não vão conseguir isso de uma única chamada SearchVectors. A solução alternativa é filtrar no código da aplicação após recuperação, o que aumenta o conjunto de resultados que você paga para processar. Armazenamentos especializados lidam com isso com mais flexibilidade.

S3 Vector Buckets custam menos por consulta e escalam sem limites. A vantagem do DynamoDB é latência de recuperação em tempo real. Para memória de agentes que precisa de busca sub-10ms, DynamoDB é a escolha certa. Para fluxos de trabalho de vizinho mais próximo em lote ou recuperação offline onde uma cauda de 100ms é aceitável, S3 pode ser mais barato em escala.

A AWS já oferece busca vetorial em Aurora, RDS, MemoryDB, DocumentDB, Neptune Analytics e OpenSearch. O DynamoDB completa a camada transacional principal. Uma pesquisa Futurum de profissionais de dados na primeira metade de 2026 descobriu que 33,4% preferem um mecanismo in-database como sua estratégia de longo prazo para incorporação de vetores — o maior bloco único. Arquitetos escolhendo entre um armazenamento de vetores dedicado e uma abordagem consolidada têm uma razão a menos para executar um serviço separado se o DynamoDB já estiver na stack.