Fim da complexidade híbrida: vetores e dados transacionais unificados
Até então, arquiteturas que exigiam busca semântica sobre dados armazenados no DynamoDB eram forçadas a replicar informações para bancos de dados vetoriais dedicados (como OpenSearch, Pinecone ou pgvector), mantendo pipelines de sincronização complexos e custosos. Com o anúncio, a AWS elimina essa etapa: **embeddings e itens da aplicação agora coexistem na mesma tabela**.
A busca vetorial utiliza um **novo tipo de índice do DynamoDB**, construído sobre atributos do tipo vetor. O desenvolvedor escolhe o modelo de embedding de preferência — Amazon Bedrock (Titan), Cohere, OpenAI ou qualquer outro —, define as dimensões (até **4.096**), a função de distância (Euclidiana, Cosseno ou Produto Interno) e passa a consultar via a nova API **`SearchVectors`**.
Casos de uso habilitados nativamente
Segundo **Esra Kayabali**, Principal Solutions Architect da AWS, o recurso desbloqueia cargas de trabalho como:
# publicidade
- **Memória agente (Agentic Memory)** e **RAG (Retrieval-Augmented Generation)**;
- **Motores de recomendação** e experiências personalizadas em tempo real;
- **Detecção de anomalias** e classificação semântica de alto volume.
A promessa é de **latência de dígitos únicos de milissegundos** mesmo em escala de **trilhões de vetores**, graças à arquitetura serverless do DynamoDB que escala horizontalmente sem provisionamento de infraestrutura.
Modelo de custo: três dimensões de cobrança
Em artigo técnico assinado por **Leonid Koren** (Principal NoSQL Specialist SA) e **Mo Kamioner** (Senior DynamoDB SA), a AWS detalha a precificação do índice vetorial, cobrada **além** dos custos padrão da tabela base. A cobrança ocorre por GB em três frentes:
1. **Escrita no índice** (ingestão dos vetores);
2. **Dados processados na busca** (leitura durante a query ANN);
3. **Armazenamento do índice** (persistência).
**Estratégias de otimização de custo** recomendadas pelos autores:
- Reduzir dimensionalidade dos embeddings quando possível;
- Usar projeções mínimas no índice (evitar replicar atributos desnecessários);
- Excluir o próprio vetor de embedding do resultado da consulta (`returnEmbeddings: false`);
- Aplicar particionamento seletivo e filtros inline para limitar o espaço de busca.
Recepção da comunidade e comparações
O anúncio gerou debates técnicos nas redes. **Jeff Barr** (VP & Chief Evangelist) destacou a escala 'ilimitada' com latência previsível. Críticos apontaram que a AWS chegou 'atrasada à festa', dado que concorrentes (MongoDB, PostgreSQL/pgvector, Redis, Cassandra) já oferecem busca vetorial há anos.
Por outro lado, **Humayun Khan** celebrou a simplificação arquitetural: *'Manter busca vetorial e dados da aplicação em um só lugar torna a construção de apps com IA muito mais simples'*.
Uma dúvida técnica recorrente — se filtros de atributo são aplicados **antes** ou **depois** da busca vetorial (pré-filtro vs. pós-filtro) — não foi explicitamente respondida no anúncio inicial, mas a documentação confirma suporte a **filtragem inline (inline filtering)**, sugerindo execução integrada para eficiência.
Comparação com **S3 Vector Buckets**: usuários notaram que o S3 oferece escala 'ilimitada' com latência consistente (porém maior) e custo potencialmente menor para cargas de trabalho de *batch* ou arquivamento, enquanto o DynamoDB foca em **baixa latência transacional** para aplicações interativas.
Disponibilidade e ecossistema local
O recurso já está **disponível em todas as regiões** onde o DynamoDB opera, compatível com as classes de tabela **Standard** e **Standard-IA**.
Para desenvolvimento local e implantações *self-managed*, a AWS planeja integrar o suporte vetorial ao **ExtendDB** (adapter compatível com DynamoDB), facilitando testes *offline* e ambientes *air-gapped*.
