A AWS adicionou busca vetorial nativa ao Amazon DynamoDB, permitindo armazenar embeddings ao lado dos dados da aplicação e rodar consultas de vizinho mais próximo aproximado (ANN) diretamente na tabela, sem depender de um banco vetorial dedicado. O recurso suporta buscas por similaridade com filtros e índices de vetores configuráveis para cargas de trabalho de busca semântica.

O problema que isso resolve

Até agora, quem usava o DynamoDB e precisava de busca por similaridade tinha que copiar os dados para um banco vetorial separado e manter os dois sistemas sincronizados. Isso significava um pipeline extra de dados, mais transferência entre serviços e mais complexidade arquitetural, com todos os pontos de falha que uma sincronização entre dois bancos costuma trazer.

A busca vetorial nativa elimina essa camada: embeddings e dados da aplicação passam a viver e ser consultados na mesma tabela. Para quem constrói RAG (geração aumentada por recuperação), memória de agentes, motores de recomendação, personalização ou detecção de anomalias, some um sistema inteiro do desenho.

Como funciona na prática

O recurso usa um novo tipo de índice do DynamoDB, construído sobre embeddings guardados em atributos da tabela. O fluxo é:

• Escolher o modelo de embedding, como Amazon Bedrock Titan Text Embeddings, Cohere Embed ou os modelos de embedding da OpenAI;
• Criar um índice de vetores informando o número de dimensões e a função de distância;
• Consultar usando a nova API SearchVectors.

Segundo Esra Kayabali, principal solutions architect da AWS, os índices de vetores não têm limite de armazenamento e escalam horizontalmente conforme os dados crescem. Ela destaca que, por o DynamoDB ser totalmente serverless, "a busca vetorial escala automaticamente, sem infraestrutura para gerenciar". O suporte vai até 4096 dimensões, com funções de distância Euclidiana, Cosseno e Produto Escalar (Dot product), além de filtragem inline.

Jeff Barr, VP e chief evangelist da AWS, afirmou no LinkedIn que o recurso "escala tão grande quanto você quiser (pense em trilhões de vetores), mantendo latência de milissegundos de dígito único".

O exemplo dos papers de pesquisa

Num tutorial da AWS, "Build semantic search with native vector support in Amazon DynamoDB", Leonid Koren e Mo Kamioner mostram como montar um app de busca semântica em Python que usa embeddings do Bedrock e o DynamoDB para encontrar artigos científicos relevantes por significado, e não por correspondência exata de palavras-chave. É o caso de uso clássico: recuperar documentos conceitualmente próximos da consulta mesmo que eles não contenham as palavras literais digitadas.

A conta: onde o custo mora

Este é o ponto que exige atenção de quem desenha arquitetura no Brasil, onde o câmbio pesa em cima da fatura da AWS. Segundo os autores do tutorial, um índice de vetores é cobrado em três dimensões, além das cobranças padrão do DynamoDB pela tabela que guarda os itens:

• Os dados que você escreve no índice;
• Os dados processados quando você faz uma busca;
• Os dados que você armazena.

Os três são medidos por byte e cobrados por GB. As técnicas apontadas para reduzir custo de forma significativa são usar dimensões menores, projeções mínimas no índice, excluir os embeddings dos resultados e usar particionamento seletivo.

A comparação com S3 vector buckets aparece na discussão da comunidade. O usuário coinclick pondera que o "S3 tem escala ilimitada e latência consistente, mesmo que a latência não seja ótima", e que o DynamoDB provavelmente escala bem com latência muito baixa, "mas será provavelmente bem mais caro que o S3". Ou seja: a escolha entre índice vetorial no DynamoDB e S3 vector buckets vira um trade-off de latência versus custo que cada arquitetura precisa medir.

Reação da comunidade

Nem todo mundo aplaudiu. Como muitos bancos já entregaram suporte a vetores nos últimos dois anos, parte dos praticantes classifica a AWS como "atrasada para a festa". Do outro lado, Humayun Khan comenta que a novidade "é uma adição realmente empolgante" e que "a busca vetorial nativa no DynamoDB pode tornar a construção de aplicações com IA muito mais simples ao manter busca vetorial e dados da aplicação num só lugar".

Uma dúvida técnica ficou em aberto na comunidade: se o DynamoDB aplica os filtros de atributos antes ou depois da busca vetorial. A ordem importa e impacta tanto a qualidade dos resultados quanto o custo (busca em conjunto maior é mais cara), mas o comportamento não foi detalhado.

O que muda para o dev brasileiro

Para quem já roda arquiteturas serverless com DynamoDB no Brasil, isso significa uma peça a menos para provisionar, sincronizar e pagar separadamente. Times menores, que muitas vezes não têm gente sobrando para operar um Pinecone, OpenSearch ou pgvector à parte, ganham a possibilidade de subir RAG e memória de agentes usando um serviço que já dominam e que já está no desenho.

A disponibilidade também é ampla: segundo a AWS, os índices de vetores estão liberados em todas as regiões onde o DynamoDB já existe e funcionam com tabelas das classes Standard ou Standard-IA. Vale acompanhar a chegada do suporte via ExtendDB, o adaptador compatível com DynamoDB que o time planeja usar para desenvolvimento local e deploys autogerenciados, útil para quem quer testar sem custo de nuvem.

Fonte: https://aws.amazon.com/pt/about-aws/whats-new/2026/08/amazon-dynamodb-vector-search/