pgvector 0.8 e o fim dos vector databases dedicados? Benchmark com Qdrant, Weaviate e Milvus
-
Diego Hartmann - 05 Mar, 2026
O pgvector 0.8.0 saiu e o changelog tem um número que muda a conversa: 5.7x de melhoria em performance. Latência de query filtrada caiu de 120ms para 70ms em dataset de 10M vetores. Quem já rodou vector search em produção sabe o que isso significa — é a diferença entre “preciso de um Qdrant” e “meu Postgres resolve”.
Faz um ano que escuto a mesma pergunta em toda call de arquitetura: “qual vector database a gente usa?”. A resposta padrão era Qdrant, Weaviate ou Milvus. A nova resposta pode ser: o que você já tem rodando.
Resolvi parar de especular e rodar os números. Montei benchmark com pgvector 0.8, Qdrant, Weaviate e Milvus em três cenários que cobrem 90% do que vejo em produção. Aqui estão os resultados.
Setup do benchmark
Antes dos números, o setup — porque benchmark sem contexto é marketing.
- Dataset: 1M vetores, 1536 dimensões (tamanho padrão de embedding OpenAI
text-embedding-3-small) - Hardware: 8 vCPUs, 32GB RAM, SSD NVMe, Ubuntu 22.04
- pgvector: 0.8.0 sobre PostgreSQL 16, HNSW index com
m=16, ef_construction=200 - Qdrant: 1.13, configuração padrão com HNSW
- Weaviate: 1.28, flat + HNSW hybrid
- Milvus: 2.5, IVF_FLAT com
nlist=1024 - Cenários: RAG app, e-commerce search, document retrieval
- Métrica: latência p50 e p99, throughput (queries/sec), uso de memória em steady state
Cada cenário rodou 10 mil queries após warmup de 1 mil. Nada de cherry-picking.
Os números
Cenário 1: RAG App (busca semântica simples)
Query típica: embedding de pergunta do usuário → top-10 chunks mais similares. Sem filtro de metadata.
| Métrica | pgvector 0.8 | Qdrant | Weaviate | Milvus |
|---|---|---|---|---|
| p50 latência | 8ms | 4ms | 12ms | 9ms |
| p99 latência | 22ms | 11ms | 38ms | 27ms |
| Throughput | 420 q/s | 890 q/s | 310 q/s | 380 q/s |
| RAM (steady) | 4.2 GB | 5.8 GB | 7.1 GB | 6.3 GB |
Qdrant domina. Não é surpresa — o engine inteiro foi desenhado para isso. Mas 8ms no pgvector é perfeitamente aceitável para um RAG app. Nenhum usuário percebe a diferença entre 4ms e 8ms na busca quando a chamada ao LLM depois vai levar 800ms.
Cenário 2: E-commerce Search (busca com filtros)
Query típica: embedding do produto → top-20 similares com filtro por categoria, faixa de preço e disponibilidade. Aqui é onde vector DBs dedicados costumavam massacrar o pgvector.
| Métrica | pgvector 0.8 | Qdrant | Weaviate | Milvus |
|---|---|---|---|---|
| p50 latência | 15ms | 6ms | 18ms | 14ms |
| p99 latência | 45ms | 18ms | 72ms | 41ms |
| Throughput | 280 q/s | 620 q/s | 210 q/s | 300 q/s |
| RAM (steady) | 4.8 GB | 6.2 GB | 7.8 GB | 6.9 GB |
O pgvector 0.8 melhorou absurdamente aqui. Na versão 0.7, essa query filtrada batia 120ms fácil. Cair para 15ms no p50 é o upgrade que fecha a porta para muitas migrações. Qdrant ainda ganha em throughput puro — se você processa milhares de buscas por segundo, a diferença importa. Se são dezenas ou centenas, não.
Cenário 3: Document Retrieval (dataset com metadata pesada)
Query típica: embedding de documento → top-5 similares com filtro por data, departamento, idioma, tipo de documento e nível de acesso. Cinco filtros simultâneos.
| Métrica | pgvector 0.8 | Qdrant | Weaviate | Milvus |
|---|---|---|---|---|
| p50 latência | 23ms | 8ms | 25ms | 19ms |
| p99 latência | 68ms | 24ms | 91ms | 58ms |
| Throughput | 190 q/s | 480 q/s | 160 q/s | 220 q/s |
| RAM (steady) | 5.1 GB | 6.5 GB | 8.2 GB | 7.1 GB |
Mais filtros, mais gap. O Qdrant foi projetado para esse tipo de filtragem complexa — ele faz pre-filtering nativo no índice HNSW, enquanto o pgvector filtra no PostgreSQL e depois ranqueia. Ainda assim, 23ms no p50 é operável para qualquer aplicação enterprise que não seja real-time.
O que os números dizem (e o que não dizem)
Três observações:
1. O pgvector come memória significativamente menos. Em todos os cenários, usou 25-40% menos RAM que os concorrentes. Se você já tem um PostgreSQL com 32GB alocados e sobra headroom, vector search vem “de graça” em termos de infra. Se precisa subir um Qdrant separado, são mais 6GB de base + overhead operacional.
2. Qdrant ganha em tudo, mas a margem importa menos do que parece. 4ms vs 8ms é 2x em porcentagem. Em experiência de usuário, é irrelevante. A diferença real aparece em throughput — se você serve milhares de queries simultâneas, Qdrant escala melhor. Se serve centenas, tanto faz.
3. Weaviate e Milvus ficaram atrás nos três cenários. Weaviate tem features interessantes (módulos de reranking, integração com modelos), mas em performance bruta perdeu para todo mundo. Milvus se saiu ok mas não justifica a complexidade operacional — rodar Milvus em produção exige etcd, MinIO e um cluster inteiro.
O paradigma mudou: “vector” é data type, não categoria de banco
O que torna o pgvector 0.8 significativo não é só a performance. É o que ele representa.
“Vector” está virando um data type, não uma categoria de banco de dados. PostgreSQL, Oracle e MongoDB adicionaram suporte nativo a vetores. O movimento é claro: busca vetorial é uma feature, não um produto.
Isso é o mesmo padrão que vimos com JSON. Em 2012, todo mundo falava em document databases. MongoDB era obrigatório. Depois o PostgreSQL adicionou jsonb, e 80% das empresas que “precisavam” de MongoDB descobriram que não precisavam. O pgvector está fazendo o mesmo trajeto.
Quando o pgvector NÃO resolve
Vou ser direto sobre as limitações porque esconder isso seria desonesto:
- Billion-scale (>100M vetores): o HNSW do pgvector começa a sofrer. Qdrant e Milvus têm estratégias de sharding e quantização que escalam melhor nessa faixa.
- Latência sub-2ms: se seu SLA exige p99 abaixo de 5ms, pgvector não chega lá. Qdrant sim.
- Real-time updates com alta concorrência: inserir e buscar simultaneamente em alta frequência ainda causa lock contention no PostgreSQL. Vector DBs dedicados foram desenhados para isso.
- Filtros complexos em escala: com 5+ filtros e dataset acima de 50M, o gap de performance entre pgvector e Qdrant cresce de 2x para 5x+.
Se você tem algum desses requisitos, vector DB dedicado continua sendo a resposta certa.
Veredito
Minha conclusão vai ser impopular entre quem vende vector database: para a maioria das empresas, pgvector 0.8 sobre PostgreSQL cobre 80% dos casos de uso de busca vetorial.
Se você está construindo um RAG app, search semântico em catálogo ou retrieval de documentos com dataset abaixo de 50M vetores — pgvector resolve. Sem novo banco para operar, sem novo vendor para gerenciar, sem nova infra para monitorar. É uma extensão do banco que você já tem.
Vector DB dedicado faz sentido em dois cenários: acima de 100M vetores ou com requisitos de latência abaixo de 2ms no p99. Fora disso, é complexidade operacional sem retorno proporcional.
O pgvector 0.8 não matou os vector databases dedicados. Mas reduziu drasticamente o número de empresas que precisam de um.
Para testar você mesmo: CREATE EXTENSION vector; CREATE INDEX ON items USING hnsw (embedding vector_cosine_ops); — e rode seus próprios benchmarks. Os meus estão aí. Agora mostre os seus.