pgvector vs Qdrant: benchmark com 100 000 vetores de 1536 dimensões

A discussão sobre usar "Postgres com extensão ou um banco vetorial separado" costuma se resumir a afirmações categóricas. O Machine Learning Mastery propôs trocá-las por medições: pgvector e Qdrant rodam em Docker na mesma máquina, com os mesmos 100 000 vetores de 1536 dimensões (o tamanho do OpenAI text-embedding-3-small) e as mesmas configurações de índice HNSW. O resultado aparece em quatro métricas: latência mediana (p50), as caudas p95 e p99 e o número de consultas por segundo.

Uma discussão sem números

A história típica é esta. Numa terça-feira, a equipe adiciona o pgvector a um Postgres que já está em produção. Os embeddings ficam ao lado dos dados relacionais, e uma única consulta filtra e busca itens similares ao mesmo tempo. Seis meses depois, chega um e-mail de um fornecedor dizendo que é hora de migrar para um banco vetorial "de verdade" antes que se bata no teto. O e-mail não traz benchmark, só convicção.

O pgvector é uma extensão open source para Postgres, hoje na versão 0.8.6, compatível com Postgres 13 e posteriores. Ela adiciona o tipo nativo vector e a busca de vizinhos mais próximos, exata e aproximada. O vetor fica na mesma tabela do registro que ele descreve (e, se quiser, na mesma linha) e é consultado com SQL comum. Não há serviço separado, não é preciso sincronizar uma segunda fonte de dados e não existe salto de rede entre a parte relacional e a vetorial. A extensão suporta vetores de precisão simples e meia precisão, binários e esparsos, além de cinco funções de distância: L2, produto interno, cosseno, L1 e Hamming.

Os cinco bancos dedicados usados como comparação com o

Postgres

Um banco vetorial dedicado é um serviço à parte, com processo e armazenamento próprios, projetado desde o início para busca vetorial. O custo dessa escolha é conhecido: o novo sistema precisa ser implantado, monitorado, ter backup e ser sincronizado com a fonte da verdade. O autor analisa as cinco opções mais populares:

• Pinecone — banco em nuvem totalmente gerenciado, sem configuração, pensado para escala corporativa com o mínimo de operação.
• Qdrant — banco de alto desempenho escrito em Rust, forte em consultas rápidas com filtragem complexa por payload JSON.
• Weaviate — sistema open source voltado para IA, com vetorização embutida e busca híbrida com BM25.
• Milvus — banco distribuído com aceleração por GPU para cargas massivas, na casa de bilhões de vetores.
• ChromaDB — banco leve e embarcável para prototipagem local e desenvolvimento em Python.

Para a comparação prática, foi escolhido o Qdrant: ele tem o benchmark público mais detalhado e metodologicamente transparente contra o pgvector, e o material se baseia nele.

Como funciona uma medição justa

O Postgres 17 com a extensão sobe a partir da imagem pgvector/pgvector:pg17, e o Qdrant, com um único comando docker run nas portas 6333 e 6334. Nos dois sistemas, a dimensão é 1536 e a métrica é cosseno. O dataset é sintético: 100 000 vetores de uma distribuição normal com seed=42 fixo, normalizados para comprimento unitário, como fazem os modelos de embeddings reais. No Qdrant, os dados são carregados em lotes de 1000 pontos; no Postgres, pelo adaptador pgvector-python.

A decisão-chave é que os índices são idênticos. No pgvector, cria-se um HNSW com m=16 e ef_construction=64 (os valores padrão), e no Qdrant os mesmos valores são definidos via HnswConfigDiff. O autor escreve de forma direta que comparar com parâmetros de índice diferentes produz dois resultados incomparáveis. Do lado das consultas, hnsw.ef_search também é 64, e o limite de resultados é 10.

As consultas usam 200 vetores novos, que não estão no conjunto carregado. Caso contrário, um vetor que já está no índice encontraria a si mesmo a distância zero, e a medição perderia o sentido. O tempo é medido com perf_counter, as latências são ordenadas, p95 e p99 são tiradas pelas posições na lista ordenada, e o QPS é o número de consultas dividido pelo tempo total da execução.

Como aplicar isso no seu caso

Para repetir o teste, são necessários Docker com Compose, Python 3.10+ e cerca de 8 GB de memória livre. Não é preciso conta em nenhuma nuvem.

A lógica prática da escolha decorre da própria arquitetura. Se os dados já vivem no Postgres e a consulta precisa combinar filtro por campos relacionais com busca por similaridade, o pgvector dispensa um segundo sistema e a sincronização. Se a necessidade é filtrar campos JSON complexos em alta velocidade, o Qdrant é uma boa opção. Para coleções de bilhões de vetores, considera-se o Milvus; para operação zero, o Pinecone; para vetorização embutida e BM25, o Weaviate.

Um conselho além da metodologia: vetores normais aleatórios não têm a estrutura de clusters dos embeddings reais, e o script mede apenas latências. Antes de decidir por uma migração, rode o mesmo teste com os seus próprios embeddings e adicione uma verificação de recall em relação à busca exata.