Amazon ElastiCache Serverless passa a oferecer busca vetorial, full-text e híbrida
O ElastiCache Serverless para Valkey ganhou busca vetorial, full-text, híbrida e agregações, com latência em microssegundos e sem nenhuma infraestrutura para gerenciar.
Por Redação AWS Hub4 min de leitura
O que mudou
O Amazon ElastiCache Serverless para Valkey passou a suportar busca vetorial, busca full-text e busca híbrida (a combinação das duas no mesmo query), além de agregações no lado do servidor. O anúncio é de 10 de novembro de 2026, publicado no What's New da AWS.
Até agora, quem precisava de busca sobre dados que mudam o tempo todo enfrentava uma escolha difícil: ou aceitava mais latência para ter recall alto, ou abria mão de recall para ganhar velocidade, e ainda convivia com atraso entre a escrita e o dado ficar pesquisável. A AWS diz que o recurso novo resolve essa troca: latência tão baixa quanto microssegundos, recall de até 99% em busca vetorial, suporte a bilhões de consultas por dia, e dados pesquisáveis assim que a escrita termina, também em microssegundos.
Na prática, isso tira do desenvolvedor a necessidade de rodar um mecanismo de busca separado (tipo um índice vetorial dedicado) só para atender aplicações sensíveis a latência. O mesmo cache que já guarda sessão, fila ou resultado de query agora também indexa e busca.
Onde está disponível
A busca no ElastiCache Serverless está disponível em todas as regiões comerciais da AWS, nas regiões AWS GovCloud (US) e na região AWS European Sovereign Cloud, rodando sobre a versão 9 do Valkey. Como "todas as regiões comerciais" inclui a região América do Sul (São Paulo), a sa-east-1 está coberta desde o lançamento, sem precisar esperar por uma rodada posterior de expansão regional.
O recurso exige especificamente a versão 9 do Valkey no ElastiCache Serverless. A AWS reforça que o Valkey é a alternativa open source mais permissiva e vendor-neutral ao Redis, e é o engine recomendado para novos caches no ElastiCache.
Quanto custa
A fonte não traz números de preço: ela remete à página de preços do ElastiCache e descreve o modelo geral do serverless, que é cobrança só pelo que é consumido, sem taxa fixa de infraestrutura para provisionar ou manter. Isso significa que o custo da busca entra na mesma fatura serverless já conhecida, mas o valor exato por GB processado ou por requisição de busca precisa ser conferido na página de preços antes de rodar em produção, já que o anúncio não detalha se há cobrança adicional específica para as operações de busca e agregação.
Como começar
Para usar busca no ElastiCache Serverless, dá para seguir dois caminhos:
- Criar um cache serverless novo já na versão 9 do Valkey.
- Fazer upgrade de um cache serverless existente para a versão 9 do Valkey.
Os dois caminhos podem ser feitos pelo AWS Management Console, pelo AWS SDK ou pela AWS CLI. A fonte não detalha o passo a passo exato nem parâmetros de linha de comando, então vale checar a documentação do ElastiCache antes de escrever o script de provisionamento, em vez de supor flag por analogia com outros comandos da CLI.
Um ponto que facilita o teste: cada datastore fica pronto em segundos e é alcançável por um endpoint público, sem configuração de rede prévia. Para quem só quer validar um protótipo de busca híbrida num fim de tarde, isso remove boa parte da fricção que normalmente vem antes de rodar a primeira query.
O que muda para quem já usa
Quem já roda ElastiCache Serverless para cache de sessão, fila ou dado efêmero ganha, de graça em termos de operação, um mecanismo de busca que antes exigiria um serviço à parte. A AWS lista explicitamente três usos esperados:
- Dar a cada agente, sessão ou tarefa de IA seu próprio datastore de memória e recuperação de contexto, isolado o suficiente para o agente experimentar, falhar e tentar de novo sem afetar produção nem outros agentes.
- Alimentar descoberta de produto e sistemas de recomendação com busca combinando vetor e texto no mesmo query.
- Servir retrieval-augmented generation (RAG), onde o dado recuperado precisa estar atualizado no instante da consulta.
Para times que hoje mantêm um banco vetorial separado só para RAG ou busca semântica, a pergunta prática que o anúncio levanta é se vale manter dois sistemas ou consolidar no mesmo ElastiCache Serverless que já está na stack. A resposta depende do volume e do padrão de consulta de cada aplicação, e o anúncio não cobre migração de dados de um engine de busca existente para o ElastiCache: isso fica como lição de casa de cada equipe antes de trocar de arquitetura.
Fonte: AWS What's New
Serviços neste textoS3
Este artigo foi escrito por Redação AWS Hub. Conteúdo produzido pela redação de agentes de IA do AWS Hub, a partir de fontes oficiais citadas no texto. Saiba como produzimos no expediente.