Escolha o Vector Database pelo Que Quebra Primeiro

Quase todo sistema de retrieval deveria começar com pgvector no Postgres que você já opera, e a pergunta de seleção não é "qual vector database é mais rápido" e sim "qual modo de falha me alcança primeiro". Os números publicados de recall e QPS convergem entre os motores nas escalas em que a maioria dos times realmente opera. O que não converge é o que acontece quando você adiciona um filtro de tenant a cada consulta, quando o índice precisa de um rebuild em horário comercial, ou quando o grafo HNSW deixa de caber na RAM. Esses são os eventos que forçam uma migração, e cada motor falha em um deles de forma diferente.

Portanto, a maneira honesta de comparar vector stores é trabalhar de trás para frente a partir da quebra. Escolha a falha que você vai atingir primeiro, depois escolha o motor que não a tem. Todo o resto é uma grade de features.

As quatro coisas que realmente quebram

Em sistemas de RAG e de memória de agentes em produção, quatro sintomas respondem por quase toda migração para fora da escolha inicial:

• Tempo de build e rebuild do índice. Você troca o modelo de embedding, ou a dimensão, ou o operador de distância, e agora precisa reconstruir um índice de vizinhos mais próximos aproximados sobre cada linha. Com um milhão de vetores isso é um café. Com cinquenta milhões é uma janela de manutenção, e você precisa decidir se o índice antigo serve o tráfego enquanto o novo é construído.
• Recall em buscas filtradas. Quase ninguém roda uma consulta vetorial sem filtro em produção. Consultas reais são "vizinhos mais próximos where tenant_id = X and status = active and updated_at > Y". Índices de grafo são construídos para o caso sem filtro, e um filtro seletivo pode fazer uma busca ANN retornar menos do que as k linhas que você pediu, silenciosamente. Isso é um problema de corretude vestido de problema de relevância.
• Memória do grafo versus RAM. HNSW é um grafo, e ele quer viver na memória. Quando o grafo mais o seu working set excedem o que a instância tem, a latência não degrada de forma suave, ela despenca de um penhasco conforme a máquina começa a ler páginas do índice do disco a cada sondagem.
• Atraso de frescor sob carga de escrita. Memória de agentes e ferramentas de suporte escrevem o tempo todo. Cada insert muta o grafo, a manutenção do índice compete com o tráfego de consultas, e a lacuna entre "armazenamos o fato" e "o fato é recuperável" passa a importar por corretude, não por sensação.

Note o que não está nessa lista: consultas por segundo em estado bruto. Se você está servindo retrieval para um modelo que depois gasta dois segundos gerando, uma diferença de dez milissegundos na latência de busca é ruído. The latency that hurts in RAG lives in the number of round trips, não na sondagem ANN.

pgvector: o default correto, e seus tetos reais

O argumento a favor do pgvector não é que ele vence benchmarks. É que seus embeddings vivem na mesma transação que a linha que descrevem, seus filtros são SQL comum contra colunas que já têm índices, sua história de backup e recuperação point-in-time é a que você já opera, e seu plantão já sabe ler um EXPLAIN. Essa combinação vale muito p99.

Os tetos são específicos e valem ser memorizados, porque o medo vago deles causa mais migrações prematuras do que os próprios tetos jamais causaram:

• Limites de dimensão são limites de índice, não de coluna. Uma coluna vector aceita até 16.000 dimensões, mas HNSW e IVFFlat só indexam até 2.000. Use halfvec (floats de 16 bits) e você indexa até 4.000 dimensões com cerca de metade do armazenamento. bit indexa até 64.000 dimensões para quantização binária, e sparsevec lida com até 1.000 elementos não nulos. Um embedding de 3.072 dimensões não é motivo para sair do Postgres, é motivo para fazer cast para halfvec na expressão do índice.
• Consultas filtradas deixaram de ser um penhasco na 0.8.0. A falha antiga era real: um scan HNSW retornava seus candidatos de ef_search, sua cláusula WHERE apagava a maioria deles, e você recebia três linhas de volta quando pediu dez. O pgvector 0.8.0 adicionou iterative index scans, que continuam escaneando até terem linhas sobreviventes suficientes. hnsw.iterative_scan = strict_order preserva a ordenação exata por distância, relaxed_order troca um pouco de ordenação por recall melhor. Se o seu modelo mental do filtering do pgvector é de 2024, ele está desatualizado.
• A memória de build é o que morde de verdade. O HNSW é construído em memória quando o grafo cabe dentro de maintenance_work_mem, e cai para um caminho em disco muito mais lento quando não cabe. A correção é elevá-la para o build e usar workers paralelos, mas existe um tamanho a partir do qual você está planejando um rebuild em vez de executando um.
• Vizinhos barulhentos são um problema arquitetural. Um build de ANN saturando a CPU da instância que serve seu fluxo de checkout é o modo de falha que nada tem a ver com vetores. Uma réplica de leitura ou uma instância separada resolve, o que também é o momento em que o pgvector deixa de ser de graça.

Na AWS especificamente, Aurora PostgreSQL com pgvector é um vector store de primeira classe para Bedrock Knowledge Bases, então escolhê-lo não custa nenhuma feature de RAG gerenciado. Escrevi sobre o lado de custo disso em the OpenSearch Serverless to Aurora migration post, com uma ressalva abaixo: o lado OpenSearch daquela comparação mudou em maio de 2026.

OpenSearch: você está comprando um motor de busca, então use-o como um

Escolher OpenSearch puramente como vector store é o jeito caro de obter busca vetorial. Escolhê-lo porque você precisa de busca, e vetores são uma das coisas com que você busca, é uma decisão diferente e muito melhor.

O que ele entrega que um vector store puro não entrega: busca lexical de verdade ao lado de ANN, de modo que retrieval híbrido combinando BM25 com similaridade vetorial é uma consulta, não uma arquitetura. Correspondência exata de palavras-chave para os números de peça, códigos de erro e identificadores em que embeddings são notoriamente ruins. Agregações, facetas e um motor de filtragem construído para atributos de alta cardinalidade em vez de anexado depois. E vetores binários, que no Bedrock Knowledge Bases apenas as duas opções de OpenSearch suportam.

O argumento contra ele historicamente foi o piso: o OpenSearch Serverless cobrava em OCUs com um mínimo de produção que custava dinheiro de verdade antes de você indexar um único documento. Esse é o argumento sobre o qual meu post de migração foi construído, e ele precisa de uma correção. A próxima geração do OpenSearch Serverless entrou em disponibilidade geral em 28 de maio de 2026 com computação e armazenamento totalmente desacoplados, scale-to-zero e um autoscaling que a AWS descreve como vinte vezes mais rápido que a geração anterior. A AWS afirma até 60 por cento de economia em relação a provisionar um cluster para o pico de carga. Se sua carga de trabalho é intermitente, e retrieval agêntico é extremamente intermitente, o velho argumento do piso não se aplica mais na forma em que eu o fiz.

O que ainda quebra: é um sistema distribuído com shards, réplicas e um estado de cluster, e ele eventualmente vai pedir que você pense nos três. Dimensionar shards para cargas vetoriais não é o mesmo que para logs. E um rebuild é um reindex, o que significa planejar capacidade para duas cópias do índice.

S3 Vectors: uma camada de armazenamento que responde consultas, não uma camada de serving

S3 Vectors atingiu disponibilidade geral em 2 de dezembro de 2025 com quarenta vezes a escala do preview: até dois bilhões de vetores por índice e dez mil índices por vector bucket, com mais dezessete regiões adicionadas em março de 2026. A AWS coloca a redução de custo em relação a rodar um vector database em até 90 por cento, e o motivo é estrutural, não promocional: não há cluster, não há computação provisionada e não há cobrança por ociosidade.

O número que decide se ele serve é o perfil de latência. A AWS documenta consultas infrequentes retornando em menos de um segundo, e consultas mais frequentes em cerca de 100 milissegundos ou menos. Leia isso como um efeito de cache aquecido, e então seja honesto sobre o seu tráfego: um assistente de suporte que recebe quarenta perguntas por hora não está mantendo nada aquecido. Sub-segundo é aceitável para um job noturno de sumarização e errado para um chat interativo em que o modelo ainda precisa dos seus próprios dois segundos.

Onde ele é genuinamente a resposta certa: camadas vetoriais frias ou de arquivo, índices por tenant onde a contagem de tenants é grande e o tráfego de cada tenant é esparso, Bedrock Knowledge Bases orientadas a custo com orçamentos de latência tolerantes, e qualquer cenário em que a alternativa era pagar por um cluster ocioso. Ele compõe bem como segunda camada sob um store quente, que é como eu o usaria, em vez de como substituição total.

Qdrant, Milvus, Pinecone: quando o payload vence

Você sai do Postgres para um motor dedicado quando a carga vetorial deixou de ser uma feature da sua aplicação e virou a aplicação. Três formas disso:

Qdrant é o que se pega quando filtragem é o problema. Seus payload indexes e seu HNSW filtrável são projetados para o caso que o iterative scan do pgvector apenas sobrevive: filtros altamente seletivos em toda consulta, em taxas altas. Ele também traz quantização escalar, por produto e binária, que é o jeito prático de manter um índice grande residente em memória. Para um store de memória de agentes multi-tenant com filtros por tenant em cada leitura, esse é um motivo defensável para rodar outro banco de dados.

Milvus é a resposta na escala de bilhões. Indexação em disco (DiskANN) significa que o working set não precisa caber na RAM, que é o que muda a conta de hardware nesse tamanho. A troca é operacional: é um sistema distribuído com papéis separados de coordenador, consulta, dados e índice, e rodá-lo em produção é uma decisão de equipe antes de ser uma decisão técnica. Abaixo de algumas centenas de milhões de vetores, essa complexidade compra muito pouco.

Pinecone é a opção de comprar em vez de construir, e deve ser avaliado como se avalia qualquer SaaS: pela carga operacional que remove, não pela latência. O preço serverless desacopla armazenamento de leituras e escritas sem custo de ociosidade, o que serve a cargas com picos e torna implantações pequenas genuinamente baratas. O que você abre mão é do controle sobre os modos de falha, e assume egress e acoplamento a fornecedor. Ele também é um store suportado pelo Bedrock Knowledge Bases, então não é uma saída do caminho de RAG gerenciado da AWS.

A cauda longa, em resumo

Weaviate é o mais próximo de um store de RAG com pilhas inclusas: módulos de vetorização embutidos, busca híbrida e um modelo schema-first. Atraente se você quer opiniões fornecidas, menos se você já tem um pipeline de embeddings. Chroma é uma ferramenta de prototipagem que é honesta sobre isso, e toda implantação séria que vi acabou migrando para fora dele. Redis com similaridade vetorial é excelente quando os vetores são efêmeros, sessões, memória de agentes de curto prazo, caches semânticos, e péssimo como sistema de registro. MongoDB Atlas Vector Search é para o Mongo o que o pgvector é para o Postgres: correto se seus documentos já vivem lá, e um motivo ruim para adotar Mongo se não vivem. Tanto Redis Enterprise Cloud quanto MongoDB Atlas são stores suportados pelo Bedrock Knowledge Bases.

A tabela de decisão

Os gatilhos que realmente significam "saia do pgvector agora"

Não escala no abstrato. Estes:

• Seu rebuild de HNSW não cabe mais em uma janela de manutenção aceitável, e você já elevou maintenance_work_mem e usou workers paralelos.
• O recall filtrado ainda fica aquém depois de habilitar iterative scans e ajustar ef_search, porque seus filtros são seletivos o bastante para que o grafo seja a estrutura errada.
• O working set do índice excede a memória da instância e o próximo tamanho de instância custa mais do que um motor dedicado custaria.
• A busca vetorial está sufocando sua carga transacional, e uma réplica de leitura não é separação suficiente.
• Você precisa de ranking híbrido lexical mais vetorial como consulta de primeira classe, e não como duas buscas que você mescla em código de aplicação. Esse aponta para o OpenSearch especificamente.

Se nenhum desses é verdadeiro, a migração que você está planejando é uma preferência, não um requisito. O time que entrega uma camada de retrieval funcionando no banco que já opera, e só se move quando um desses gatilhos dispara, chega à produção consideravelmente antes do time que gastou o primeiro sprint escolhendo.

A conclusão

Comece no pgvector, e conheça seus quatro tetos com precisão suficiente para distinguir um limite real de folclore. Migre para o OpenSearch quando precisar de busca em vez de similaridade, e refaça a comparação de custo contra a oferta serverless de próxima geração, não contra o velho piso de OCUs. Use S3 Vectors como camada fria e para índices esparsos por tenant, não como caminho de serving interativo. Recorra ao Qdrant quando a filtragem domina, ao Milvus depois do ponto em que a RAM define a conta, e ao Pinecone quando você prefere comprar as operações a executá-las. Escolha pela quebra que você vai atingir primeiro, porque essa é a única variável nesta comparação que difere de forma significativa entre os motores.

Leia isto a seguir

• Agent Memory Is a Database Problem, Not a Prompt Problem, sobre por que a camada de armazenamento decide o que seu agente consegue lembrar.
• Knowledge Base Chunking Is Where Your RAG Quality Dies, sobre o problema de retrieval que nenhum vector database resolve por você.

Para o lado de infraestrutura de rodar Postgres e clusters de busca em produção, as notas de campo de cloud vivem em ercan.cloud, e o hub fica em ercanermis.com.

Referências

• pgvector on GitHub, vector types, index types, and dimension limits.
• pgvector 0.8.0 release announcement, iterative index scans and filtering improvements.
• The next generation of Amazon OpenSearch Serverless is now generally available, AWS What's New, 28 May 2026.
• Amazon S3 Vectors is now generally available with 40 times the scale of preview, AWS What's New, 2 December 2025.
• Working with S3 Vectors and vector buckets, Amazon S3 User Guide.
• Prerequisites for using a vector store you created for a knowledge base, Amazon Bedrock User Guide.
• Approximate k-NN search, OpenSearch documentation.
• Filtering, Qdrant documentation.
• DiskANN-based on-disk index, Milvus documentation.
• Pinecone pricing, serverless read unit, write unit, and storage model.