Qdrant vs Chroma vs pgvector: Escolher a Base de Dados Vetorial Certa para RAG Autoalojado

Qdrant vs Chroma vs pgvector: Escolher a Base de Dados Vetorial Certa para RAG Autoalojado

A decisão Qdrant vs Chroma vs pgvector resume-se a um compromisso triplo: velocidade dedicada à tarefa, simplicidade de prototipagem ou permanecer dentro do PostgreSQL. Cada abordagem funciona; a questão é saber qual o compromisso que melhor se adapta ao seu pipeline RAG.

Resumo Rápido: Qual Base de Dados Vetorial Deve Escolher?

Escolha o Qdrant se necessitar de pesquisa vetorial de nível de produção com filtragem avançada, multi-inquilino (multi-tenancy) e não se importar em executar um serviço separado.

Escolha o Chroma se estiver a fazer protótipos, quiser desenvolvimento local sem configuração ou precisar de passar da ideia a um RAG funcional em menos de uma hora.

Escolha o pgvector (+ pgvectorscale) se já executar PostgreSQL e quiser pesquisa vetorial sem adicionar infraestrutura, especialmente agora que o índice StreamingDiskANN do pgvectorscale reduziu a diferença de desempenho.

Se está a construir uma aplicação RAG do zero, o restante deste artigo ajudá-lo-á a escolher a base certa.

Desempenho: Quão Rápida É Cada Base de Dados?

O desempenho torna-se relevante quando ultrapassa alguns milhares de documentos. É aqui que estas três opções divergem significativamente.

Qdrant

O Qdrant foi construído de raiz para pesquisa vetorial. A sua implementação em Rust e o índice HNSW personalizado oferecem latência consistentemente baixa; os benchmarks mostram uma latência de consulta de cerca de 94 ms mesmo sob carga concorrente. Suporta quantização escalar, binária e de produto para comprimir vetores e acelerar a pesquisa, mantendo a revocação acima de 95%.

Onde o Qdrant realmente se destaca é na pesquisa filtrada. Ao contrário das bases de dados que encontram primeiro os vizinhos mais próximos e depois filtram, o HNSW filtrável do Qdrant respeita as restrições de metadados durante a travessia do grafo. Isso significa que não perde revocação ao combinar pesquisa vetorial com filtros como category = "technical" ou date > 2025-01-01.

Chroma

O lançamento 1.0 do Chroma reescreveu o núcleo em Rust, entregando escritas e consultas 3 a 5 vezes mais rápidas em comparação com a implementação original em Python. Uma atualização subsequente em agosto de 2025 adicionou codificação de vetores em base64 para outro aumento de 70% na taxa de transferência.

Para conjuntos de dados com menos de um milhão de vetores, o Chroma é genuinamente rápido. Executa-se embutido no seu processo Python sem sobrecarga de rede, o que torna a iteração local ágil. Mas é uma base de dados de nó único; não possui fragmentação (sharding) ou replicação integradas.

pgvector + pgvectorscale

Esta é a surpresa. O pgvector vanilla com HNSW é 5.250 vezes mais rápido do que uma varredura sequencial, e o pgvector 0.8.0 adicionou varredura iterativa de índices para resolver o problema de sobre-filtragem que afetava versões anteriores.

Mas a verdadeira história é o pgvectorscale. A extensão da Timescale adiciona o índice StreamingDiskANN, inspirado pela pesquisa DiskANN da Microsoft, que armazena o índice no disco em vez da RAM. Num benchmark de 50 milhões de embeddings Cohere (768 dimensões), o pgvectorscale atingiu 471 QPS com 99% de revocação. Isso representa uma taxa de transferência 11,4 vezes superior aos 41 QPS do Qdrant no mesmo nível de revocação e uma latência p95 28 vezes menor do que o índice otimizado para armazenamento da Pinecone.

A ressalva? Estes benchmarks utilizaram uma instância EC2 robusta. Os seus resultados dependerão do hardware. Mas a trajetória é clara: o PostgreSQL já não é apenas a opção "suficientemente boa" para pesquisa vetorial; é genuinamente competitivo.

Veredito: pgvector + pgvectorscale vence nos números brutos dos benchmarks. O Qdrant vence no desempenho de pesquisa filtrada. O Chroma é suficientemente rápido para protótipos, mas não foi construído para escala.

Configuração e Experiência do Desenvolvedor

Quão rapidamente pode passar do zero para os vetores?

Qdrant: Docker e Go

O Qdrant necessita do seu próprio contentor:

docker run -p 6333:6333 -v $(pwd)/qdrant_storage:/qdrant/storage qdrant/qdrant

Depois, insira vetores através da API REST ou de um dos SDKs oficiais (Python, Rust, Go, TypeScript):

from qdrant_client import QdrantClient
from qdrant_client.models import VectorParams, Distance

client = QdrantClient(url="http://localhost:6333")
client.create_collection(
    collection_name="documents",
    vectors_config=VectorParams(size=1536, distance=Distance.COSINE),
)

O painel do Qdrant em localhost:6333/dashboard é um toque agradável; pode navegar pelas coleções, executar consultas e inspecionar payloads visualmente. O caminho do desenvolvimento para a produção é limpo: a sua configuração local do Docker funciona de forma idêntica num servidor de produção ou no Qdrant Cloud.

Chroma: pip Install e Feito

O Chroma ganha a corrida da simplicidade por uma larga margem:

import chromadb

client = chromadb.Client()  # In-memory, zero config
collection = client.create_collection("documents")
collection.add(
    documents=["Your RAG document here"],
    ids=["doc1"]
)

Sem Docker. Sem servidor. Até gera automaticamente os embeddings se não fornecer vetores. Para um protótipo RAG, pode passar de pip install chromadb para uma pesquisa funcional em menos de 10 linhas.

Quando estiver pronto para persistência, mude para chromadb.PersistentClient(path="./chroma_data"). Para acesso multiprocesso ou em rede, o Chroma tem um modo servidor, mas nesse ponto começa a perder a vantagem da simplicidade.

pgvector: SQL até ao Fim

Se o Postgres já estiver na sua stack, o pgvector é uma linha de código:

CREATE EXTENSION vector;

CREATE TABLE documents (
  id SERIAL PRIMARY KEY,
  content TEXT,
  embedding vector(1536)
);

CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops);

Tudo é SQL. Os seus embeddings vivem junto dos dados da sua aplicação na mesma transação. Não há pipeline de sincronização, nem credenciais separadas, nem serviço extra para monitorizar. Se já está a executar PostgreSQL em produção, este é o caminho de menor resistência.

Adicionar o pgvectorscale por cima é simples se utilizar a imagem Docker da Timescale ou um fornecedor de Postgres gerido que o suporte:

CREATE EXTENSION vectorscale;
CREATE INDEX ON documents USING diskann (embedding);

A desvantagem? O SQL não é tão ergonómico como a DSL de filtragem de payload do Qdrant ou a API pitónica do Chroma. E terá de gerir o seu próprio pipeline de embeddings; o pgvector não gera embeddings por si.

Veredito: Chroma vence pelo protótipo mais rápido. pgvector vence se o Postgres já estiver na sua stack. Qdrant tem o melhor equilíbrio entre experiência de desenvolvimento (DX) e prontidão para produção.

Escalabilidade e Prontidão para Produção

Fazer protótipos é uma coisa. Executar um pipeline RAG que lida com milhões de vetores com latência consistente é outra.

Qdrant: Construído para Escalar Horizontalmente

O Qdrant suporta fragmentação horizontal (sharding) nativamente. Pode distribuir coleções por vários nós, com fatores de replicação configuráveis para alta disponibilidade. O seu roteiro para 2026 inclui segregação de leitura/escrita e integração de armazenamento em blocos para uma escalabilidade ainda melhor.

A multi-inquilino (multi-tenancy) é uma funcionalidade de primeira classe. Pode particionar dados por inquilino usando filtragem baseada em payload sem criar coleções separadas, o que mantém o uso de recursos eficiente. Para sistemas de memória de agentes de IA que lidam com múltiplos utilizadores, esta é uma vantagem significativa.

A história operacional é sólida: cópias de segurança integradas, endpoints de métricas para Prometheus e recuperação de falhas baseada em WAL. O Qdrant foi desenhado para ser autoalojado em produção.

Chroma: Teto de Nó Único

O Chroma é honesto quanto aos seus limites. É uma base de dados de nó único focada na simplicidade e no desenvolvimento local. Não há fragmentação integrada, nem replicação, nem clustering.

O Chroma Cloud tornou-se geralmente disponível no início de 2026 como uma opção gerida sem servidor e distribuída, pelo que pode delegar a escala horizontal lá em vez de a executar você mesmo. Mas a história autoalojada e open-source continua a ser principalmente "um servidor, uma instância Chroma". Se o seu conjunto de dados couber numa única máquina (até alguns milhões de vetores, dependendo da dimensionalidade), tudo bem. Além disso, o Chroma autoalojado atinge um limite e terá de escolher entre o Chroma Cloud e uma migração.

pgvector: Escala com o Postgres

O pgvector herda a história de escalabilidade testada em batalha do PostgreSQL. Obtém réplicas de leitura, pooling de conexões via PgBouncer e replicação lógica. Fornecedores geridos como a Neon e plataformas Postgres sem servidor semelhantes tornam a escala vertical quase sem esforço.

O índice StreamingDiskANN do pgvectorscale é a chave para desbloquear a escala. Como armazena o índice no disco (SSDs) em vez da RAM, pode lidar com conjuntos de dados que, de outra forma, exigiriam instâncias de memória elevada dispendiosas. Com 50 milhões de vetores, já é competitivo com bases de dados vetoriais dedicadas.

A limitação é a fragmentação horizontal. O PostgreSQL não fragmenta nativamente como o Qdrant. Existem soluções como o Citus, mas adicionam complexidade. Para a maioria das cargas de trabalho RAG autoalojadas abaixo de 100 milhões de vetores, a escala vertical com pgvectorscale é suficiente.

Veredito: Qdrant vence na escalabilidade horizontal e multi-inquilino. pgvector vence na utilização da infraestrutura Postgres existente. O Chroma não foi desenhado para escala de produção.

Custo de Autoalojamento

Todos os três são open-source e gratuitos para executar. O custo real reside na infraestrutura e no tempo de engenharia.

O pgvector tem uma vantagem estrutural de custos: se já está a pagar pelo Postgres, adicionar pesquisa vetorial é essencialmente gratuito até precisar de recursos dedicados. Não há contentor extra, nem monitorização extra, nem estratégia de cópia de segurança extra.

O uso de recursos do Qdrant é eficiente para o seu conjunto de funcionalidades, mas é um serviço separado; terá de considerar a sobrecarga operacional de executar e monitorizar outra peça de infraestrutura.

O Chroma é o mais barato na fase de protótipo (zero infraestrutura), mas torna-se o caminho mais dispendioso se tentar escalá-lo além do que um único nó consegue suportar.

Para implementar estes em plataformas cloud, tanto o Qdrant como o pgvector têm implementações baseadas em Docker diretas. O Chroma também funciona, mas perde a simplicidade embutida que é o seu principal argumento de venda.

Veredito: pgvector vence no custo total de propriedade. Elimina um serviço inteiro da sua stack. O Qdrant tem um preço razoável pelo que oferece. A história de custos do Chroma só funciona durante a prototipagem.

Filtragem e Pesquisa Híbrida

O RAG não é apenas "encontrar o vetor mais próximo". Precisa de combinar pesquisa de similaridade com filtros de metadados, intervalos de datas, controlos de acesso e, por vezes, correspondência de palavras-chave.

Qdrant: O Rei da Filtragem

A filtragem de payload do Qdrant ocorre durante a travessia HNSW, não depois. Esta é uma distinção crítica. A pós-filtragem pode reduzir a contagem de resultados abaixo do que pediu; a pré-filtragem garante que obtém k resultados que correspondem às suas restrições.

A DSL de filtragem é expressiva:

from qdrant_client.models import Filter, FieldCondition, MatchValue

results = client.search(
    collection_name="documents",
    query_vector=embedding,
    query_filter=Filter(
        must=[
            FieldCondition(key="category", match=MatchValue(value="engineering")),
            FieldCondition(key="year", range=Range(gte=2024)),
        ]
    ),
    limit=10,
)

O Qdrant também suporta pesquisa híbrida nativa com vetores densos e esparsos na mesma consulta, o que é útil para combinar compreensão semântica com precisão de palavras-chave.

Chroma: Básico mas Utilizável

O Chroma suporta filtragem de metadados com cláusulas where:

results = collection.query(
    query_embeddings=[embedding],
    where={"category": "engineering"},
    n_results=10,
)

Funciona para casos simples, mas a filtragem ocorre após a pesquisa vetorial. Com filtros restritivos e conjuntos de dados pequenos, pode obter menos resultados do que o esperado. Não há suporte para vetores esparsos nem pesquisa híbrida integrada.

pgvector: O SQL É o Seu Superpoder

O pgvector herda todo o poder do SQL para filtragem:

SELECT content, embedding <=> $1 AS distance
FROM documents
WHERE category = 'engineering'
  AND created_at > '2024-01-01'
  AND content @@ to_tsquery('RAG & retrieval')
ORDER BY distance
LIMIT 10;

Essa última linha combina similaridade vetorial com a pesquisa de texto completo integrada do PostgreSQL numa única consulta. Não é necessário nenhum motor de busca externo. Pode fazer joins com a sua tabela de utilizadores para controlo de acesso, agregar resultados, usar CTEs, tudo o que o SQL puder fazer.

A varredura iterativa do pgvector 0.8.0 também ajuda. Se a varredura HNSW inicial não devolver resultados filtrados suficientes, continua automaticamente a pesquisar em vez de devolver um conjunto parcial.

Veredito: Qdrant vence na filtragem complexa de metadados em escala. pgvector vence na flexibilidade de pesquisa híbrida (SQL + texto completo + vetor numa consulta). A filtragem do Chroma é adequada apenas para protótipos.

Quando Usar Cada Um: Estrutura de Decisão

Aqui está a versão em árvore de decisão: A sua app já usa Postgres? Se sim, comece com pgvector; pode sempre migrar mais tarde se o ultrapassar. Se não, está a fazer protótipos ou a construir para produção? Prototipagem vai para Chroma. Produção vai para Qdrant.

A abordagem "começar simples, migrar mais tarde" é válida porque todos os três suportam formatos de embedding padrão. Mover vetores entre eles é uma migração de dados, não uma reescrita de arquitetura.

O Fator pgvectorscale: Por Que Razão o Postgres Está a Alcançar

Vale a pena deter-nos nisto, pois altera o cálculo para muitas equipas.

Antes do pgvectorscale, a crítica ao pgvector era sempre "funciona bem abaixo de um milhão de vetores, mas não escala". Isso era verdade. Os índices HNSW residem inteiramente na RAM e, assim que o seu conjunto de dados excede a memória disponível, o desempenho cai a pique.

O StreamingDiskANN muda a equação. Ao armazenar o índice de grafo em SSD em vez de RAM, o pgvectorscale lida com 50 milhões de vetores a 471 QPS com 99% de revocação. A Quantização Binária Estatística (SBQ) comprime vetores com perda mínima de precisão; a revocação cai de 98,6% para 96,5% mesmo com compressão agressiva.

O impacto prático: uma equipa a executar um pipeline RAG no Postgres já não precisa de planear uma migração para uma base de dados vetorial dedicada "quando as coisas ficarem sérias". Para muitas cargas de trabalho, pgvector + pgvectorscale é a opção séria.

Dito isto, o pgvectorscale não é uma bala de prata. É uma extensão da TigerData (anteriormente Timescale), pelo que precisa da sua imagem Docker ou de um fornecedor que a inclua. Um lançamento de 2026 adicionou pesquisa vetorial filtrada baseada em etiquetas ao StreamingDiskANN, inspirada pela pesquisa Filtered DiskANN da Microsoft, o que reduz a liderança de longa data do Qdrant em consultas filtradas. Mas se precisar de isolamento multi-inquilino ou suporte nativo para vetores esparsos, o Qdrant ainda tem vantagem.

Como a Techsy Aborda a Seleção de Bases de Dados Vetoriais

Quando construímos pipelines RAG para clientes, o nosso processo de avaliação é o seguinte:

1. Auditar a stack existente. Se a equipa já executa Postgres, o pgvector é o ponto de partida padrão. Não faz sentido adicionar complexidade de infraestrutura sem uma razão clara.
2. Perfilizar os padrões de consulta. Filtragem pesada de metadados com campos de alta cardinalidade? Isso empurra para o Qdrant. Pesquisa semântica simples? pgvector ou Chroma servem.
3. Estimar a trajetória de escala. Menos de 5M de vetores e permanecer aí? Qualquer opção serve. Planeia 50M+? pgvectorscale ou Qdrant, dependendo do passo 2.
4. Verificar a capacidade operacional da equipa. Uma startup de duas pessoas não deve gerir um cluster Qdrant. Um fornecedor de Postgres gerido com pgvector é geralmente a escolha certa.

Construímos sistemas RAG de produção com os três. A resposta honesta é que a escolha da base de dados importa menos do que a sua estratégia de fragmentação (chunking), o modelo de embedding e o design do pipeline de recuperação. Se está a gastar mais tempo a debater Qdrant vs pgvector do que a testar diferentes tamanhos de fragmentos, está a otimizar a coisa errada.

Precisa de ajuda para desenhar um pipeline RAG? A seleção de armazenamento vetorial e o design de recuperação fazem parte do nosso serviço de integração de IA. Contacte-nos e ajudá-lo-emos a escolher a base certa e a construir a camada em torno dela.

Perguntas Frequentes

O pgvector é suficientemente bom para RAG de produção?

Sim, especialmente com pgvectorscale. O índice StreamingDiskANN lida com mais de 50 milhões de vetores com 99% de revocação a níveis de taxa de transferência que superam bases de dados vetoriais dedicadas em benchmarks. Se já executa Postgres, raramente há razão para adicionar uma base de dados vetorial separada para RAG.

O Chroma pode escalar para milhões de vetores?

O Chroma pode lidar com alguns milhões de vetores num único nó com RAM suficiente, mas não tem escalabilidade horizontal integrada. Para conjuntos de dados além do que uma única máquina pode suportar, terá de migrar para Qdrant, pgvector ou um serviço gerido.

O Qdrant suporta pesquisa híbrida com palavras-chave?

Sim. O Qdrant suporta vetores densos e esparsos na mesma coleção. Pode executar consultas híbridas que combinam similaridade semântica (densa) com correspondência de palavras-chave (esparsa) e controlar a ponderação entre elas.

Quanta RAM preciso para cada base de dados?

Depende da contagem de vetores e das dimensões. Como guia aproximado: 1M de vetores a 1536 dimensões ocupa cerca de 6 GB no Qdrant ou pgvector com HNSW. O Chroma utiliza ligeiramente mais devido à sobrecarga do Python. O índice DiskANN do pgvectorscale reduz drasticamente as necessidades de RAM ao armazenar o índice em SSD.

Posso migrar entre estas bases de dados mais tarde?

Sim. Todos os três funcionam com arrays float padrão, pelo que os vetores são portáteis. Terá de recriar índices e adaptar a sua camada de consulta, mas é uma migração de dados, não uma reescrita. A maioria das ferramentas de migração, como a ferramenta oficial de migração do Qdrant, simplifica este processo.

Qual funciona melhor com LangChain e LlamaIndex?

Todos os três têm integrações oficiais com LangChain e LlamaIndex. O Chroma é frequentemente o padrão em tutoriais, tornando-o o mais suave para começar. As integrações do Qdrant e pgvector são igualmente maduras para uso em produção. Consulte o nosso guia sobre as melhores ferramentas RAG para uma visão mais ampla do ecossistema.

Devo usar pgvector ou pgvectorscale?

Use ambos. O pgvector fornece o tipo vector central e o índice HNSW. O pgvectorscale adiciona o StreamingDiskANN por cima para melhor desempenho em escala. São extensões complementares, não alternativas.

O Qdrant é gratuito para autoalojar?

Completamente gratuito sob a licença Apache 2.0. O Qdrant Cloud é a opção gerida paga, começando com um nível gratuito de 1 GB. Para autoalojamento, apenas paga pela infraestrutura de computação.

E quanto ao Milvus ou Weaviate?

Ambos são alternativas sólidas. O Milvus é mais forte em escala muito grande (milhares de milhões de vetores) com aceleração GPU. O Weaviate tem um pipeline de vetorização integrado agradável. Mas para RAG autoalojado abaixo de 100M de vetores, Qdrant, Chroma e pgvector cobrem a vasta maioria dos casos de uso com menos complexidade operacional.

O pgvector pode lidar com consultas RAG concorrentes em produção?

Sim. O PostgreSQL foi desenhado para cargas de trabalho concorrentes. O pgvector herda pooling de conexões (PgBouncer), réplicas de leitura e controlo de concorrência MVCC. Para RAG de alta taxa de transferência, emparelhe o pgvector com um pooler de conexões e ajuste shared_buffers e effective_cache_size.

Veredito Final

Global: Para a maioria dos pipelines RAG autoalojados, pgvector + pgvectorscale é a escolha pragmática. É suficientemente rápido, escala para dezenas de milhões de vetores e mantém a sua stack simples. Já conhece SQL. A sua equipa já gere o Postgres. Um serviço a menos significa uma coisa a menos para avariar às 2 da manhã.

Se precisar de pesquisa filtrada avançada, multi-inquilino ou estiver a construir um produto onde a pesquisa vetorial é a funcionalidade central (não um recurso de suporte), Qdrant é o investimento certo. É a base de dados vetorial open-source mais completa por uma razão.

Chroma ganha o seu lugar como ferramenta de prototipagem. Use-o para validar a sua abordagem RAG, testar diferentes estratégias de fragmentação e iterar sobre a qualidade da recuperação. Quando estiver pronto para a produção, migre para whichever of the other two fits your stack (qualquer um dos outros dois que se adapte à sua stack).

O melhor conselho? Pare de debater e comece a construir. Escolha pgvector se tiver Postgres, Qdrant se não tiver, e faça o seu pipeline RAG funcionar. Pode sempre mudar o armazenamento vetorial mais tarde; o modelo de embedding, a estratégia de fragmentos e a lógica de recuperação importam muito mais.

Fontes

• Benchmarks do Qdrant
• Lançamento Chroma 1.0: 4x Mais Rápido
• pgvectorscale: StreamingDiskANN para PostgreSQL
• pgvector É Agora Mais Rápido que Pinecone com 75% Menos Custo
• pgvector 0.8.0: Varredura Iterativa de Índices
• Preços do Qdrant