Vector stores na AWS
Onde guardar os embeddings: OpenSearch Serverless, Aurora pgvector e outras opções.
6 min de leitura
Escolha como aprender
— combine como quiserDica: o vídeo é um resumo visual rápido — o áudio e o texto trazem a aula completa.
Você já tem seus embeddings — agora precisa de um lugar para guardá-los, indexá-los e buscá-los em milissegundos. A escolha do vector store define latência, custo e complexidade operacional do seu RAG. Na AWS, as opções principais são OpenSearch Serverless, Aurora PostgreSQL com pgvector, Neptune Analytics e MemoryDB — cada uma com um perfil diferente de custo, escala e operação.
O que é um vector store — e por que não é só um banco de dados
Um vector store é um sistema de armazenamento e busca otimizado para vetores de alta dimensão (tipicamente 256–4096 dimensões). A busca tradicional compara valores exatos; a busca vetorial compara distâncias — cosine similarity, produto interno, distância euclidiana. Para fazer isso em escala sem varrer todos os vetores, os vector stores usam índices ANN (Approximate Nearest Neighbor), sendo o HNSW (Hierarchical Navigable Small World) o mais comum: ele organiza os vetores em camadas de grafos que permitem navegação logarítmica em vez de linear.
O ponto prático: HNSW troca um pequeno grau de imprecisão ("approximate") por velocidade e memória viáveis. Em produção, você raramente percebe essa imprecisão — o recall costuma ficar acima de 95% com parâmetros bem configurados.
Além da busca vetorial pura, produção exige filtros de metadados ("só documentos do cliente X", "só versão vigente"), busca híbrida (vetorial + BM25 — tema da aula 05) e controle de acesso. Nem todo vector store entrega os três com a mesma maturidade. Escolher o errado significa reescrever a camada de dados quando o volume cresce ou quando o cliente pede isolamento de dados.
Vector stores na AWS: onde cada opção se encaixa
Fluxo de um pipeline RAG mostrando as diferentes opções de vector store disponíveis na AWS e seus perfis de uso.
- Aplicação RAG · Orchestrator
- Embedding Model · Bedrock / Titan
- OpenSearch Serverless · HNSW + BM25 híbrido
- Aurora pgvector · Postgres nativo
- Neptune Analytics · Grafo + vetores
- MemoryDB · In-memory / baixa latência
- Bedrock LLM · Claude / Titan / etc.
As quatro opções na AWS — perfis reais
Amazon OpenSearch Serverless (AOSS) com vector engine é a opção mais completa para RAG na AWS hoje. Entrega busca vetorial HNSW, busca full-text BM25 e a combinação das duas (busca híbrida) no mesmo índice. Escala automaticamente, sem gerenciar shards ou instâncias. O custo é baseado em OCUs (OpenSearch Compute Units) — você paga pelo que usa, mas o mínimo de 2 OCUs por coleção significa que projetos pequenos podem pagar mais do que pagariam com uma instância provisionada. A integração com Bedrock Knowledge Bases (aula 09) é nativa.
Aurora PostgreSQL com pgvector é a escolha certa quando você já opera Postgres e o volume de vetores é manejável (tipicamente abaixo de alguns milhões). pgvector suporta HNSW e IVFFlat, filtros SQL completos e transações ACID. O custo é previsível — você paga pela instância Aurora, não por consulta. A desvantagem: sem busca híbrida nativa (você implementa BM25 com tsvector manualmente), e a performance de busca vetorial em escala grande fica atrás do OpenSearch.
Neptune Analytics faz sentido quando seus dados têm estrutura de grafo — entidades, relacionamentos, hierarquias. RAG sobre grafos de conhecimento é um caso real, mas de nicho. Se você não tem grafo, não force.
MemoryDB for Redis com suporte a vetores entrega latências sub-5ms, ideal para RAG em tempo real (chat ao vivo, assistentes de voz). O trade-off: custo de memória é alto, e o volume de vetores que você consegue guardar é limitado pelo tamanho do cluster.
Quando usar cada vector store
OpenSearch Serverless
- Busca híbrida nativa (vetor + BM25) sem código extra
- Escala automática — sem gerenciar shards
- Integração nativa com Bedrock Knowledge Bases
- Filtros de metadados robustos
- Mínimo de 2 OCUs por coleção — caro para projetos pequenos
- Custo imprevisível em picos de ingestão
- Não é relacional — sem JOINs com dados transacionais
Escolha padrão para RAG em produção com volume médio/alto ou necessidade de busca híbrida
Aurora pgvector
- Sem nova infraestrutura se você já usa Postgres
- Filtros SQL completos e JOINs com dados relacionais
- Custo previsível (instância fixa)
- ACID — consistência transacional
- Busca híbrida manual via tsvector — mais código
- Performance vetorial cai em volumes acima de ~5M vetores
- Sem integração nativa com Bedrock Knowledge Bases
Ideal quando você já opera Postgres, volume é menor e simplicidade operacional importa
Neptune Analytics
- Combina busca vetorial com traversal de grafo
- Ideal para RAG sobre grafos de conhecimento
- Nicho — só faz sentido com dados em grafo
- Curva de aprendizado de Gremlin/openCypher
- Sem busca híbrida nativa
Use apenas se seus dados já são um grafo de conhecimento
MemoryDB (Redis)
- Latência sub-5ms — o mais rápido da lista
- Bom para RAG em tempo real (voz, chat ao vivo)
- Custo de memória alto por vetor armazenado
- Volume limitado pelo tamanho do cluster
- Sem busca híbrida nativa
Use quando latência é o requisito dominante e o volume de vetores é pequeno
Na prática, para a maioria dos projetos RAG em produção na AWS, começo com OpenSearch Serverless. A busca híbrida nativa e a integração com Bedrock Knowledge Bases economizam semanas de trabalho. O custo do mínimo de 2 OCUs dói em POCs — nesses casos uso pgvector numa Aurora Serverless v2 com auto-pause, que custa centavos quando inativa. Quando o projeto cresce e precisa de busca híbrida de verdade, migro para OpenSearch. Nunca escolho MemoryDB como vector store principal — o custo de memória não justifica exceto em casos muito específicos de latência crítica.
Critérios de escolha: o que realmente importa em produção
Além do perfil técnico, três critérios definem a escolha em produção:
Escala e crescimento previsível. OpenSearch Serverless escala sem intervenção, mas cobra por OCU consumido. Aurora pgvector tem teto de performance — se você projeta crescer para dezenas de milhões de vetores, planejar uma migração depois é caro. Dimensione com folga.
FinOps: serverless vs. provisionado. Serverless (AOSS) tem custo variável — ótimo quando o tráfego é imprevisível, ruim quando você tem carga constante e alta. Para carga constante e alta, OpenSearch provisionado (não serverless) pode ser 40–60% mais barato. Para carga baixa e intermitente, Aurora Serverless v2 com auto-pause ganha. A aula 12 aprofunda o modelo de custo completo do pipeline.
Filtros de metadados e isolamento de tenants. Se você tem múltiplos clientes no mesmo índice, filtros de metadados são críticos para segurança. OpenSearch e pgvector suportam filtros robustos. Mas o design do índice importa: filtros em campos não indexados são lentos. Planeje os campos de filtro antes de criar o índice — mudar depois exige reindexação completa.
Operação e expertise do time. Se seu time já opera Postgres, pgvector tem curva de adoção zero. Se ninguém conhece OpenSearch, serverless reduz o overhead operacional significativamente — você não gerencia cluster, shards ou upgrades.
Vector stores na AWS
Toque num conceito e depois na definição.
Comparativo rápido: vector stores na AWS
| Critério | OpenSearch Serverless | Aurora pgvector | Neptune Analytics | MemoryDB | |
|---|---|---|---|---|---|
| Busca híbrida nativa | ✅ Sim | ⚠️ Manual (tsvector) | ❌ Não | ❌ Não | — |
| Escala (vetores) | Alta (bilhões) | Média (~5M) | Média | Baixa (RAM-bound) | — |
| Filtros de metadados | ✅ Robusto | ✅ SQL completo | ⚠️ Limitado | ⚠️ Básico | — |
| Integração Bedrock KB | ✅ Nativa | ✅ Nativa | ❌ Não | ❌ Não | — |
| Modelo de custo | OCU (variável) | Instância (fixo) | Instância (fixo) | Memória (alto/GB) | — |
| Latência de busca | ~10–50ms | ~20–100ms | ~20–80ms | < 5ms | — |
| Overhead operacional | Baixo (serverless) | Baixo (familiar) | Médio | Médio | — |
O que levar desta aula
Perguntas frequentes
Posso usar OpenSearch provisionado (não serverless) como vector store?
Sim. OpenSearch Service provisionado suporta o mesmo vector engine HNSW e busca híbrida. Para cargas constantes e altas, pode ser 40–60% mais barato que serverless. O trade-off é operacional: você gerencia instâncias, shards e upgrades. Para a maioria dos times, serverless vale o custo extra pela simplicidade.
Bedrock Knowledge Bases suporta pgvector como vector store?
Sim, desde 2024 o Bedrock Knowledge Bases suporta Aurora PostgreSQL com pgvector como opção de vector store gerenciado, além do OpenSearch Serverless. A integração é nativa — você aponta para o cluster Aurora e o Bedrock gerencia a ingestão e a busca.
Qual a diferença entre HNSW e IVFFlat no pgvector?
HNSW tem melhor recall e performance de busca, mas usa mais memória e tem build de índice mais lento. IVFFlat tem build mais rápido e menor footprint de memória, mas recall inferior. Para RAG em produção, prefira HNSW — a diferença de recall importa quando você está buscando os top-k chunks mais relevantes.
Como funciona o isolamento de dados entre tenants no mesmo índice OpenSearch?
Você adiciona um campo de metadados (ex: tenant_id) em cada documento e aplica um filtro obrigatório em todas as queries. O OpenSearch suporta filtros pré-query que são aplicados antes da busca vetorial, garantindo que um tenant nunca veja dados de outro. Importante: esse campo precisa ser mapeado como keyword no índice para performance adequada.
Minha posição
Vector store não é uma decisão de commodities — ela afeta latência, custo e o que você consegue fazer com busca híbrida. Na AWS, OpenSearch Serverless é a escolha madura para produção: entrega busca híbrida sem código extra, escala sem operação e integra nativamente com Bedrock. pgvector é a escolha pragmática quando você já tem Postgres e volume menor. Não complique: escolha a opção que seu time consegue operar bem, com os filtros que seu caso de uso exige, e dimensione com folga. Reindexar bilhões de vetores porque você escolhou errado é um problema caro de ter.