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.