pgvector, Qdrant, Pinecone ou Weaviate: Qual Vector Database Usar em 2026

Em 2023, quando o hype de RAG explodiu, apareceram dezenas de vector databases. Chroma, Milvus, Redis com RediSearch, Vespa, LanceDB, Deep Lake — cada semana havia um novo competidor prometendo ser o melhor em algo. Times de engenharia se perdiam comparando benchmarks de papers diferentes, com metodologias incompatíveis, rodados em hardware diferente.

Em 2026, o mercado consolidou. Não porque os outros players morreram — muitos ainda existem e têm nichos válidos — mas porque quatro opções se estabeleceram como as escolhas padrão para a maioria dos casos de uso: pgvector, Qdrant, Pinecone e Weaviate.

Cada um deles representa uma filosofia diferente de como resolver o problema de busca vetorial em produção. E o erro mais comum que os times cometem na hora de escolher não é escolher o "pior" dos quatro — é escolher pelo hype do momento ou pela popularidade em posts de blog em vez de pelo fit com o caso de uso real.

Esse post faz uma comparação honesta dos quatro: com as vantagens reais, as desvantagens que os marketing sites não mencionam, e um framework de decisão por padrão de uso.

---

Contexto: O Que Mudou de 2023 para 2026

Antes de entrar nas comparações, vale entender o que mudou no ecossistema que torna essa escolha diferente do que era dois anos atrás.

Índices HNSW se tornaram padrão. O algoritmo HNSW (Hierarchical Navigable Small World) é hoje o padrão de fato para busca aproximada de vizinhos mais próximos (ANN) em memória. Todos os quatro players o suportam, o que nivelou parte da diferença de performance bruta que existia antes. Comparações de performance de 2021-2022 que mostram gaps grandes entre soluções são obsoletas para qualquer base que use HNSW em ambos os lados.

Hybrid search deixou de ser diferencial e virou requisito. Combinar busca densa (embeddings) com busca esparsa (BM25) para casos onde queries têm componente lexical foi o grande tema de 2024-2025. Em 2026, qualquer vector database que não suporte hybrid search nativo está fora das considerações para a maioria das aplicações de produção. O mercado se adaptou.

Prompt caching e long context mudaram a equação de trade-off. Com janelas de contexto grandes e caching barato, há casos de uso que migraram de RAG para long context, reduzindo a pressão sobre os vector databases para uso em corpora pequenos. O que sobrou para o vector database é exatamente onde ele é insubstituível: corpora grandes, alta frequência de queries, auditabilidade.

---

pgvector: A Extensão Que Mudou o Jogo

O que é: pgvector é uma extensão do PostgreSQL que adiciona suporte a tipos de dados vetoriais e índices HNSW para busca por similaridade. Desde a versão 0.5.0 (lançada em 2023), o HNSW nativo transformou o pgvector de uma curiosidade para uma opção legítima de produção.

A filosofia: "Use o banco que você já tem." Em vez de adicionar uma nova peça de infraestrutura para gerenciar, adicione uma extensão ao PostgreSQL que já está em produção. Você mantém joins nativos com seus dados transacionais, transações ACID, o RBAC que você já configurou, e a operação do banco que o time já conhece.

Onde pgvector genuinamente ganha:

Para corpora até 5M vetores com dimensão de embedding padrão (1536 para text-embedding-3-small da OpenAI, 768 para modelos menores), pgvector com HNSW performa de forma comparável aos vector databases dedicados. Benchmarks do ANN-Benchmarks mostram que pgvector está dentro de margem relevante de Qdrant e Pinecone nessa escala quando bem configurado — com parâmetros m e ef_construction ajustados para o caso de uso.

A vantagem que nenhum benchmark de performance captura é a eliminação de infraestrutura. Não há novo SLA para gerenciar, não há novo serviço para monitorar, não há nova dependência de VPC para configurar, não há curva de aprendizado de uma nova API. Se o seu time já opera PostgreSQL, o custo operacional de pgvector é quase zero. Isso tem valor real.

Joins nativos são uma vantagem que vector databases dedicados simplesmente não conseguem replicar com a mesma eficiência. "Busque os documentos mais similares ao query do usuário, mas apenas nos documentos que pertencem ao tenant do usuário e foram publicados no último mês" — isso é uma query SQL com WHERE clause em pgvector. Em Qdrant ou Pinecone, é um filtered search que tem sua própria complexidade de implementação e trade-offs de performance.

Onde pgvector perde:

Acima de 10M vetores, os problemas começam a aparecer. O índice HNSW do pgvector é construído e mantido em memória — para 10M vetores com dimensão 1536, estamos falando de dezenas de gigabytes de RAM só para o índice. PostgreSQL não foi desenhado para gerenciar memória dessa forma, e os problemas de performance em escala grande são reais.

Hybrid search nativo não existe em pgvector. Você pode usar pg_trgm para busca textual e combinar com pgvector para busca vetorial, mas não é um hybrid search integrado — é você mesmo escrevendo a fusão dos resultados, o que tem complexidade de implementação e limitações de performance.

Multi-tenancy em escala é outro ponto fraco. Se você tem um SaaS B2B com 10.000 tenants, cada um com seus próprios documentos, gerenciar isolamento eficiente em pgvector requer estratégias que adicionam complexidade e têm overhead de performance.

Para quem: Times que já operam PostgreSQL, corpus até 5M vetores, sem necessidade de hybrid search sofisticado, que valorizam simplicidade operacional acima de tudo o mais.

---

Qdrant: Performance e Custo-Benefício em Self-Hosted

O que é: Qdrant é um vector database open source escrito em Rust, com cloud gerenciado disponível. É o representante da filosofia de "vector database dedicado com operação controlada pelo time."

A filosofia: Performance previsível, custo-benefício em self-hosted, e controle total sobre configuração e dados.

Onde Qdrant genuinamente ganha:

Em raw query performance, Qdrant lidera ou está empatado com Milvus nos benchmarks mais recentes — significativamente acima de pgvector em escala média e grande, e competitivo com Pinecone sem o custo de cloud gerenciado. A implementação em Rust contribui para latência consistente sob carga: o tempo de resposta no P99 é mais estável do que em implementações em Python ou Java, onde GC pauses podem causar picos inesperados.

Filtered search é onde Qdrant tem uma vantagem arquitetural clara. O Qdrant implementa filtros de metadados diretamente no processo de busca vetorial — não como um pós-processamento dos resultados, mas como uma restrição que guia o traversal do grafo HNSW. Isso significa que "busque os 10 vetores mais similares dentre os documentos com status=active e category=contrato e data_publicacao>2026-01-01" performa de forma previsível, sem a degradação que aparece quando você aplica filtros pesados sobre resultados de busca vetorial em arquiteturas que tratam filtragem como pós-processamento.

O fato de ser open source com cloud tier é relevante do ponto de vista de lock-in. Você pode começar self-hosted, avaliar em produção com custo baixo, e migrar para o cloud gerenciado se o overhead de operação ficar pesado — sem mudar de API ou de arquitetura.

Onde Qdrant perde:

Self-hosted tem overhead real. Se o time não tem experiência operacional com sistemas distribuídos, manter um cluster Qdrant em produção — backups, failover, scaling, upgrades — tem custo de engenharia que não aparece nos benchmarks. O cloud tier do Qdrant existe justamente para isso, mas o preço começa a se aproximar do Pinecone em escala maior.

A documentação ainda é inferior ao Pinecone, que tem anos de investimento em developer experience. Para casos de uso comuns, o Qdrant docs é suficiente. Para casos específicos ou edge cases, você vai passar mais tempo no GitHub Issues do que gostaria.

Para quem: Times com capacidade operacional para self-hosted, corpus médio (1M a 50M vetores), queries com filtros complexos de metadados, que querem price-performance sem depender de um vendor de cloud gerenciado.

---

Pinecone: Zero Ops, Serverless, e Preço Enterprise

O que é: Pinecone é um vector database proprietário, totalmente gerenciado, com arquitetura serverless. É o produto que mais contribuiu para popularizar vector databases ao tornar o getting started trivialmente fácil.

A filosofia: "Zero configuração de infraestrutura. Você foca na aplicação, a gente opera o banco."

Onde Pinecone genuinamente ganha:

O time de zero é literal. Você cria um index no console ou via API, começa a upsert vetores, e faz queries — sem nenhuma configuração de infraestrutura, sem decisão de hardware, sem parâmetros HNSW para ajustar. Para times de produto que querem incorporar busca vetorial sem ter engenharia de infraestrutura dedicada, esse onboarding é genuinamente superior a qualquer alternativa self-hosted.

Em escala acima de 5M vetores, o Pinecone tem vantagem de maturidade operacional. O sistema foi desenhado para operar nessa escala desde o início, e o auto-scaling serverless lida com picos de query sem intervenção manual. Para produtos com carga variável — plataformas B2C com picos em determinados horários ou eventos — isso tem valor real.

O SLA enterprise e o suporte dedicado são fatores reais para empresas que precisam de garantias contratuais de disponibilidade e tempo de resposta de suporte. Qdrant self-hosted não tem SLA. pgvector tem o SLA do seu cloud provider de PostgreSQL. Pinecone tem SLA próprio com suporte dedicado para tiers enterprise.

Onde Pinecone perde:

O preço pode surpreender. O free tier suporta um index com 100K vetores — suficiente para experimentação, insuficiente para qualquer produção real. Em produção com volumes médios (5M vetores, 1000 queries/dia), o custo mensal é significativamente maior do que Qdrant self-hosted ou pgvector. A conta pode crescer rapidamente se você não monitorar o consumo.

Não é open source — lock-in real. Se o Pinecone mudar a precificação, descontinuar um tier ou ser adquirido, sua opção de migração é reconstruir o pipeline com outra solução. Para empresas com dependências estratégicas em busca vetorial, esse risco precisa ser avaliado.

Você não controla os parâmetros HNSW. Isso significa que não dá para otimizar o índice para o perfil específico do seu corpus. Para a maioria dos casos, os padrões do Pinecone são bons o suficiente. Para casos onde você precisa de recall muito alto e está disposto a trocar por latência maior (ou vice-versa), a falta de controle é uma limitação real.

Compliance pode ser um problema. Seus dados ficam nos servidores do Pinecone — você não controla onde. Para empresas com requisitos de residência de dados ou que operam em setores regulados, isso pode ser um bloqueador.

Para quem: Times que não querem nenhum overhead operacional, corpus grande (5M+ vetores), empresas enterprise que pagam pelo SLA e suporte, casos onde time-to-production é crítico.

---

Weaviate: Hybrid Search Como Cidadão de Primeira Classe

O que é: Weaviate é um vector database open source com cloud gerenciado, construído com hybrid search e multi-tenancy como capacidades nativas de primeira classe — não como add-ons.

A filosofia: "Busca vetorial e busca textual integradas nativamente, com suporte a multi-tenancy para SaaS."

Onde Weaviate genuinamente ganha:

Hybrid search no Weaviate é uma única linha de query. Você especifica o alpha (peso entre busca densa e esparsa), e o Weaviate faz a fusão BM25 + dense internamente com reciprocal rank fusion. Não há necessidade de implementar duas buscas separadas e fundir os resultados manualmente — que é o que você faz com a maioria das outras soluções. Para times que precisam de hybrid search sem quer implementar a fusão do zero, isso é uma vantagem de developer experience real.

Multi-tenancy é suportado nativamente: você cria classes no schema e associa vetores a tenants, e o Weaviate garante isolamento de dados entre tenants eficientemente. Para SaaS B2B onde cada cliente precisa de isolamento completo dos dados de busca dos outros clientes, o Weaviate tem uma solução mais limpa do que as alternativas.

Módulos integrados para geração de embeddings são outro diferencial: o Weaviate tem módulos que chamam diretamente providers de embedding (OpenAI, Cohere, HuggingFace) durante o processo de indexação e busca. Você pode configurar o schema para usar determinado modelo de embedding e o Weaviate cuida da chamada ao provider — sem precisar chamar o provider separadamente e passar os vetores para o banco. Para times que querem menor complexidade de pipeline, isso reduz peças móveis.

Onde Weaviate perde:

Consumo de memória alto. O Weaviate tem um overhead de memória maior que Qdrant para o mesmo número de vetores. Em escala grande, esse overhead tem custo real de infraestrutura — mais RAM significa instâncias maiores e mais caras.

O setup inicial é mais complexo do que Qdrant para casos simples. O schema, os módulos, a configuração de classes — há mais conceitos para aprender antes de fazer a primeira query. Para casos onde você não precisa de hybrid search ou multi-tenancy, essa complexidade extra é overhead sem benefício.

O pricing do cloud gerenciado é caro em escala grande. Para uso intenso com corpora muito grandes, o custo do Weaviate Cloud pode superar o de alternativas como Pinecone. O ponto de equilíbrio depende do volume de queries e do tamanho do corpus.

Para quem: Times que precisam de hybrid search nativo sem implementar do zero, SaaS B2B com requisito de multi-tenancy, casos onde você quer embedding + busca numa única peça de infraestrutura.

---

Tabela de Decisão

Depois de todos os trade-offs, aqui está a síntese em formato de decisão direta. Essas são opiniões baseadas nos padrões mais comuns — não são verdades universais, e seu caso pode ter características que mudam a recomendação.

Cenário	Recomendação	Por quê
Já tenho Postgres, corpus < 5M vetores	pgvector	Zero infra adicional, joins nativos, custo operacional quase zero
Self-hosted, corpus médio, filtros complexos	Qdrant	Melhor price-performance, filtered search arquiteturalmente superior
Não quero ops, corpus grande, dinheiro disponível	Pinecone	Zero ops real, SLA enterprise, maturidade em escala
Preciso de hybrid search nativo	Weaviate	A implementação mais limpa do mercado
SaaS B2B com multi-tenancy	Weaviate	Multi-tenancy como cidadão de primeira classe
Time pequeno, começando agora	pgvector	Comece simples, migre quando encontrar o limite real

---

A Armadilha da Escolha Prematura

Há um padrão que se repete consistentemente: times escolhem o vector database antes de ter clareza sobre o padrão real de uso. Escolhem Pinecone pelo nome, Qdrant pelo benchmark, Weaviate pelo post de blog mais recente — sem saber ainda qual vai ser o tamanho do corpus em produção, qual a frequência de queries ou se vão precisar de filtros complexos.

O custo de migrar de vector database não é trivial — você precisa re-gerar embeddings se mudar o modelo, re-indexar tudo, adaptar o código de retrieval — mas também não é catastrófico. Os quatro players têm APIs razoavelmente similares no nível de operação básica.

A recomendação pragmática: se você está começando agora e não tem clareza sobre as características do uso em produção, comece com pgvector. O custo de entrada é mínimo (você provavelmente já tem PostgreSQL), e ele vai ser suficiente para a maioria dos corpora até você entender o padrão real. Quando você encontrar o limite real — seja de escala, de hybrid search, de multi-tenancy — você vai ter informação suficiente para fazer a migração para a opção certa com confiança.

Não escolha um vector database que você vai precisar operar pela próxima versão do seu produto baseado em benchmark de paper que não representa seu workload.

---

Conclusão

Os quatro players têm posicionamentos claros quando você entende a filosofia de cada um:

• pgvector é "use o que você já tem" — simplicidade operacional máxima, suficiente para a maioria dos casos até escala média.
• Qdrant é "performance + custo-benefício com controle" — o melhor price-performance em self-hosted para scale médio a grande com filtros complexos.
• Pinecone é "zero ops, eu pago pelo conforto" — o mais fácil de operar em qualquer escala, com o custo correspondente.
• Weaviate é "hybrid search e multi-tenancy sem esforço" — o mais fácil de fazer hybrid search e o mais adequado para SaaS B2B.

O mercado consolidou porque esses quatro resolvem casos de uso diferentes. Não há um vencedor universal — há o certo para o seu caso. E o erro que custa mais caro não é escolher o "segundo melhor" — é escolher sem ter clareza sobre o que o seu caso realmente exige.

---

Qual você está usando em produção e qual é o caso de uso? Sempre fico curioso sobre o que os times escolhem e por quê — me manda uma mensagem no LinkedIn, quero entender como o mercado está se comportando na prática além dos benchmarks.

---

Fontes:

• Top 5 Vector Databases 2026 — Deepak Gupta
• Vector Databases Compared: pgvector, Pinecone, Qdrant, Weaviate — Kalvium Labs
• Vector Database Performance Compared — VecStore
• Best Vector Databases 2026 — Encore.dev
• Best Vector Databases — Firecrawl