O que foi anunciado
Em 5 de agosto de 2026, a AWS tornou disponível em todas as regiões comerciais a busca vetorial nativa no Amazon DynamoDB. A novidade permite armazenar embeddings diretamente ao lado dos dados operacionais e executar buscas por similaridade sem replicar nada para um banco de dados vetorial separado.
Para entender por que isso importa, vale lembrar como era o fluxo antes. Todo projeto que precisava de recuperação semântica — um chatbot com RAG, um sistema de recomendação, memória de agente de IA — precisava de dois armazenamentos: o DynamoDB para os dados transacionais e algum serviço dedicado (OpenSearch, Pinecone, pgvector) para os vetores. Isso criava um pipeline de sincronização que precisava ser mantido, monitorado e custava latência, dinheiro e operação.
Com a novidade, você cria um vector index sobre uma tabela existente, chama a API SearchVectors e recebe os k vizinhos mais próximos do seu vetor de consulta. A infraestrutura é serverless, sem janelas de manutenção e sem provisionamento manual.
Como a busca vetorial funciona no DynamoDB
A implementação usa busca por vizinhos mais próximos aproximada (ANN — Approximate Nearest Neighbor). O vector index é um tipo de índice distinto dos GSI e LSI tradicionais: não responde a Query ou Scan, apenas à SearchVectors. Isso significa que ele não substitui seus padrões de acesso existentes — é uma camada adicional que convive com eles.
Os parâmetros principais que você define ao criar o índice:
- Dimensões: até 4.096, alinhado com os principais modelos de embedding do mercado.
- Função de distância: Euclidiana, Cosseno ou Produto Interno, conforme o modelo de embedding usado.
- Chave de partição do vector index: permite distribuir a busca por segmentos, o que habilita escalar para trilhões de vetores sem perda de latência.
Um ponto de atenção técnico: SearchVectors usa um endpoint separado (search-dynamodb.{region}.amazonaws.com), diferente do endpoint padrão do DynamoDB. Políticas IAM existentes que concedem leitura ao DynamoDB não incluem automaticamente a nova action dynamodb:SearchVectors. Isso vai pegar algumas equipes desprevenidas na primeira tentativa de integração.
| Aspecto | Arquitetura anterior | DynamoDB nativo |
|---|---|---|
| Infraestrutura | DynamoDB + banco vetorial separado | Apenas DynamoDB |
| Sincronização de dados | Pipeline próprio (DynamoDB Streams, Lambda) | Nenhuma |
| Latência de busca | Variável (depende do serviço externo) | Milissegundos de um dígito, 99%+ de recall |
| Consistência | Eventual (dados podem divergir) | Vetor e dado operacional sempre juntos |
| Custo | Dois serviços + egress de sincronização | Pay-per-request unificado |
Para que casos de uso faz mais sentido
A feature resolve melhor um problema específico: quando os dados que você quer buscar por similaridade já moram no DynamoDB e você precisava duplicá-los para conseguir fazer a busca semântica. Alguns exemplos diretos:
- Memória de agentes de IA: armazene os turnos de conversa e os embeddings na mesma tabela; a busca semântica para grounding acontece no mesmo lugar onde você grava o histórico.
- RAG sobre catálogo de produtos: se o catálogo já está no DynamoDB, adicione o vetor de embedding da descrição ao item e busque produtos semanticamente similares sem copiar nada para outro serviço.
- Sistemas de recomendação: recomendações baseadas em similaridade de perfil de usuário, sem pipeline de exportação para outro banco.
- Detecção de anomalias: vetores de comportamento junto aos registros transacionais, com busca por padrões similares.
Um detalhe que vai importar na prática: o vetor de consulta precisa ter exatamente o mesmo número de dimensões e ter sido gerado pelo mesmo modelo de embedding que os vetores armazenados. Usar modelos diferentes ou dimensões incompatíveis produz resultados sem sentido ou erro de validação. Se você mudar o modelo de embedding, vai precisar reindexar toda a tabela.
Limitações que você precisa conhecer
A funcionalidade é nova e, como toda feature recém-lançada da AWS, tem restrições que tendem a relaxar ao longo do tempo. As mais relevantes agora:
- Requer modo on-demand: vector indexes não são suportados em tabelas com capacidade provisionada. Se sua tabela usa provisionamento, migrar para on-demand é pré-requisito.
- Sem paginação em SearchVectors: as respostas são limitadas a 16 MB. Com itens grandes, projeção completa e TopK alto, esse limite pode ser atingido.
- Sem FGAC: fine-grained access control não se aplica à API SearchVectors.
- Replicação assíncrona em global tables: em tabelas multi-região, a indexação vetorial nas réplicas é assíncrona mesmo com MRSC. Buscas em regiões diferentes sobre os mesmos dados podem retornar resultados ligeiramente distintos.
- SDK mínimo: você precisa da versão 2.36.16 ou posterior do AWS CLI, ou do botocore 1.43.64+. Versões anteriores não reconhecem os novos comandos.
Migrar ou não: a decisão prática
A resposta mais honesta é: depende de onde seus dados já estão e da maturidade do seu caso de uso com busca vetorial.
Se seus dados operacionais já estão no DynamoDB e você estava pagando por um serviço vetorial separado só para fazer RAG ou busca semântica, a decisão é simples. A unificação reduz custo, elimina o pipeline de sincronização e simplifica a operação.
Se seus dados estão em outro banco, ou se você tem requisitos avançados como busca vetorial multi-tenant com isolamento fino, filtros complexos sobre bilhões de vetores ou integração com pipelines de ML que alimentam continuamente novos índices, os bancos de dados vetoriais dedicados (Pinecone, Weaviate, Qdrant e similares) ainda têm vantagens em maturidade, recursos de administração e ecossistema de ferramentas.
O movimento que a AWS está fazendo com o DynamoDB é o mesmo que o PostgreSQL fez com o pgvector: trazer a busca vetorial para dentro do banco que as equipes já conhecem e operam, reduzindo a barreira de entrada. Para a maioria das aplicações que não são especializadas em busca vetorial, essa simplificação vai valer a pena.
Antes de migrar: revise as políticas IAM do seu ambiente. A nova action dynamodb:SearchVectors precisa ser adicionada explicitamente a qualquer role que precise executar buscas vetoriais. Políticas genéricas de leitura no DynamoDB não a incluem automaticamente.
Para equipes que estão construindo ou evoluindo aplicações com inteligência artificial, essa mudança simplifica significativamente a arquitetura de referência. Em vez de orquestrar dois serviços distintos com estados que podem divergir, a aplicação passa a ter uma fonte única de verdade onde dado operacional e embedding coexistem. Isso reduz superfície de falha e facilita o raciocínio sobre consistência.