Você quer subir um chatbot com RAG, conectar um agente Claude a uma knowledge base ou só rodar uma busca semântica em cima de PDFs. Em qualquer um desses casos, você vai precisar de um vector database. Afinal, embeddings sozinhos não bastam. Por isso, escolher o vector database certo virou decisão crítica em 2026.

Neste guia, você vai comparar os cinco principais vector database em 2026: Pinecone, Qdrant, Chroma, pgvector e Weaviate. Além disso, vai ver uma tabela com latência e custo real. Por fim, vai aprender a rodar Qdrant e Chroma localmente com Docker em cinco minutos. Inclusive, vai descobrir quando NÃO usar vector database.

O que é um vector database e por que ele existe

Em termos simples, um vector database é um banco otimizado pra armazenar e buscar vetores numéricos. Esses vetores chegam ali porque um modelo de IA transformou texto, imagens ou áudio em embeddings. Cada item vira uma lista com 384, 1024 ou 1536 dimensões.

Por que isso importa? Bancos tradicionais como Postgres ou MySQL foram desenhados pra busca exata. Por exemplo, eles encontram o pedido número 12345 ou clientes da cidade de São Paulo. Já um vector database resolve um problema diferente. Ele encontra o documento que tem significado parecido com a sua pergunta, mesmo sem palavras em comum.

Veja a seguir um exemplo concreto. Suponha que você tenha 50 mil artigos numa knowledge base. Um usuário pergunta “como cuidar de gatos idosos”. Um banco tradicional buscaria por essa string literal. Já um vector database compara o vetor da pergunta com vetores de todos os artigos. Dessa forma, ele retorna o texto sobre “cuidados com felinos seniores”, mesmo sem a palavra “gato” no documento.

Por baixo dos panos, todo vector database usa o mesmo algoritmo: Approximate Nearest Neighbor (ANN). O índice mais comum em 2026 é o HNSW (Hierarchical Navigable Small World). Inclusive, ele troca um pouco de precisão por velocidade absurda. Portanto, mesmo com milhões de vetores, a busca volta em milissegundos.

Vale uma nota importante. Vector database não é só pra RAG. Da mesma forma, ele alimenta sistemas de recomendação, detecção de fraude, busca de imagens similares, deduplicação de dados e até agentic engineering em produção. Por isso, ele virou peça padrão na stack de IA.

Os 5 principais vector database

O ecossistema de vector database explodiu nos últimos dois anos. Por outro lado, cinco nomes dominam o mercado. Cada um nasceu pra resolver um problema diferente. Inclusive, conhecer essas diferenças muda completamente sua arquitetura.

Pinecone — managed cloud zero-config

Pinecone é o vector database mais popular pra produção em 2026. Ele roda 100% gerenciado na nuvem. Você não vê servidor, índice nem disco. Em troca, você paga por uso. O tier serverless cobra cerca de $70/mês pra 10 milhões de vetores. Portanto, é a escolha óbvia pra times que querem zero overhead operacional.

Qdrant — open source rápido em Rust

Qdrant é escrito em Rust e brilha em filtros complexos. Por exemplo, ele consegue buscar vetores parecidos e ao mesmo tempo filtrar por tags, datas e metadados sem perder velocidade. Além disso, ele roda perfeitamente em Docker local. A versão cloud sai por volta de $65/mês pra cargas comparáveis.

Chroma — protótipos em Python

Chroma virou o queridinho da galera Python. Ele é open source, embedded e roda dentro do próprio processo da sua aplicação. Inclusive, você instala com pip install chromadb e já tem um vector database funcionando. Em contrapartida, ele não foi pensado pra escala extrema. Portanto, use pra protótipos e MVPs, não pra produção com milhões de queries por dia.

pgvector — extensão do Postgres

pgvector é uma extensão que adiciona busca vetorial ao PostgreSQL. Se você já roda Postgres em produção, esse vector database é praticamente grátis. Da mesma forma, ele se integra com tudo que sua aplicação já tem: joins, transações, backups e replicação. Por isso, ele explodiu em popularidade no último ano.

Weaviate — enterprise multimodal

Weaviate mira empresas grandes com requisitos multimodais. Ele combina busca vetorial com GraphQL, conhecimento estruturado e até geração nativa de embeddings. Em termos de custo, fica em torno de $135/mês pra 10 milhões de vetores no cloud. Portanto, vale quando você precisa de features avançadas que os outros quatro não cobrem.

Comparativo vector database: tabela com latência, custo e features

A tabela abaixo resume os números que você precisa pra decidir. Os dados vêm de benchmarks públicos de 2026 e da documentação oficial de cada vector database. Inclusive, todos foram medidos com 10 milhões de vetores e embeddings de 1536 dimensões.

Vector database Latência p95 Custo 10M vetores Hosting Licença
Pinecone ~45 ms $70/mês Managed only Proprietary
Qdrant ~12 ms $65/mês Self-host + cloud Apache 2.0
Chroma ~30 ms Free (embedded) In-process Apache 2.0
pgvector ~5-8 ms (HNSW) $45/mês (RDS) Postgres extension PostgreSQL
Weaviate ~20 ms $135/mês Self-host + cloud BSD-3

Dados de benchmarks públicos (vectorview.ai, leanopstech, supabase) e docs oficiais. Custos referência maio/2026.

Veja uma observação importante. Custos crescem de forma diferente em cada vector database. Por exemplo, Pinecone pode chegar a $700/mês em 100 milhões de vetores. Já pgvector e Qdrant self-hosted ficam abaixo de $100/mês na mesma escala. Por isso, o custo virou um critério decisivo conforme você escala.

Como escolher um vector database por caso de uso

Fluxograma de decisão de vector database: protótipo, produção, opensource, postgres ou enterprise
Fluxograma de decisão: qual vector database usar em cada cenário em 2026.

Não existe vector database universal melhor que os outros. Em vez disso, a escolha depende do seu cenário. Por isso, veja a seguir o fluxograma de decisão que uso pra clientes em 2026. Ele cobre 90% dos casos práticos.

Decisão por caso de uso

Protótipo ou MVP
→ Chroma (embedded, sem servidor)
Produção, zero infra
→ Pinecone (managed cloud)
Open source self-host
→ Qdrant (Rust, filtros rápidos)
Já uso Postgres
→ pgvector (extensão, sem novo serviço)
Enterprise + multimodal
→ Weaviate (GraphQL, knowledge graph)

Use esse fluxograma como ponto de partida. Em casos híbridos, comece pelo mais simples.

Por outro lado, uma regra prática ajuda muito. Comece sempre pelo mais simples. Da mesma forma, suba a complexidade só quando bater num limite real. Por exemplo, um RAG novo pode começar com Chroma no laptop. Em seguida, migra pra pgvector quando o projeto vai pra staging. Por fim, troca pra Pinecone ou Qdrant quando o tráfego justifica.

Inclusive, vale lembrar de uma coisa. Migrar entre vector database é mais fácil do que parece. Afinal, o dado é só uma lista de vetores e metadados. Por isso, não se prenda à escolha inicial. Pelo contrário, otimize pra velocidade de iteração no começo.

Setup prático do vector database: Qdrant e Chroma com Docker

Chega de teoria. Vamos rodar dois vector database de verdade no seu laptop. Primeiro, garanta que você tem Docker instalado. Em seguida, execute os comandos abaixo. Você não precisa criar conta em lugar nenhum.

Comece pelo Qdrant. Veja a seguir como subir um container em segundos. Por padrão, ele expõe a porta 6333 com REST e gRPC.

Code
# Rodar Qdrant em background
docker run -d -p 6333:6333 -p 6334:6334 \
  -v $(pwd)/qdrant_storage:/qdrant/storage \
  --name qdrant qdrant/qdrant

# Verificar se subiu
curl http://localhost:6333/healthz

Pronto. Agora você tem um vector database rodando localmente. Em seguida, instale o cliente Python e popule uma coleção de teste. Execute o bloco abaixo num arquivo qdrant_demo.py.

Python
from qdrant_client import QdrantClient
from qdrant_client.models import Distance, VectorParams, PointStruct
import numpy as np

client = QdrantClient(url="http://localhost:6333")

# Cria coleção com vetores de 384 dimensões
client.create_collection(
    collection_name="meus_docs",
    vectors_config=VectorParams(size=384, distance=Distance.COSINE),
)

# Insere 3 vetores fake
client.upsert(
    collection_name="meus_docs",
    points=[
        PointStruct(id=1, vector=np.random.rand(384).tolist(),
                    payload={"texto": "guia de gatos"}),
        PointStruct(id=2, vector=np.random.rand(384).tolist(),
                    payload={"texto": "receita de bolo"}),
        PointStruct(id=3, vector=np.random.rand(384).tolist(),
                    payload={"texto": "dicas de cuidado felino"}),
    ],
)

# Busca o vetor mais parecido com um query aleatório
query = np.random.rand(384).tolist()
result = client.search(collection_name="meus_docs", query_vector=query, limit=2)
for hit in result:
    print(hit.payload, "score:", hit.score)

Agora vamos ao Chroma. Diferente do Qdrant, ele não precisa de Docker se você só quer testar. Da mesma forma, basta instalar via pip. Veja como criar uma collection persistente em poucas linhas.

Python
pip install chromadb

# chroma_demo.py
import chromadb
client = chromadb.PersistentClient(path="./chroma_db")

collection = client.get_or_create_collection(name="docs")
collection.add(
    documents=["guia de gatos", "receita de bolo", "dicas felinas"],
    ids=["1", "2", "3"],
)

# Chroma gera embeddings automáticos por baixo
results = collection.query(query_texts=["como cuidar de gatos"], n_results=2)
print(results)

Veja a diferença prática. Qdrant é mais técnico e dá controle total sobre vetores e índices. Por outro lado, Chroma é instantâneo e cuida da geração de embeddings sozinho. Portanto, use Chroma pra protótipo rápido e Qdrant quando precisar de mais performance. Inclusive, ambos integram bem com clientes como LangChain e o Model Context Protocol.

Quando NÃO usar um vector database

Vector database virou hype em 2026. Por outro lado, muita gente sobe um sem precisar. Por isso, veja três cenários onde busca tradicional supera busca vetorial. Saber isso economiza tempo e dinheiro.

Primeiro, busca exata por palavra-chave. Se o usuário sabe exatamente o termo que quer, full-text search do Postgres ou Elasticsearch resolve melhor. Por exemplo, pesquisar pelo SKU de um produto ou pelo email de um cliente. Nesses casos, BM25 ou índice GIN entregam resultado em microssegundos sem precisar de vector database.

Segundo, datasets pequenos. Abaixo de 10 mil documentos, a diferença entre busca vetorial e SQL puro é desprezível. Em contrapartida, você ganha complexidade extra sem benefício real. Por isso, comece sempre questionando se o problema realmente precisa de embeddings.

Terceiro, latência crítica em escala extrema. Se sua aplicação precisa responder em menos de 5ms com mais de 100 milhões de vetores, talvez o melhor caminho seja híbrido. Por exemplo, combine pré-filtros estruturados em SQL com busca vetorial só no subset relevante. Da mesma forma, BM25 pode entregar resultados aceitáveis sem custo de embeddings.

Quando vector database resolve o problema certo

Por fim, lembre-se: vector database resolve um problema específico. Ele brilha quando você precisa de similaridade semântica em volume alto. Por outro lado, fora desse cenário, ele só adiciona infraestrutura. Inclusive, leia mais sobre knowledge bases pra agentes IA antes de decidir.

Próximos passos

Você já entendeu o que é um vector database, comparou as cinco opções principais e rodou Qdrant e Chroma localmente. Em seguida, escolha o cenário mais próximo do seu projeto e dê o primeiro passo. Por exemplo, suba um Chroma local hoje e popule com 100 documentos do seu domínio.

Depois disso, vale aprofundar em conceitos relacionados. Por isso, confira nosso glossário de IA 2026 pra alinhar vocabulário. Da mesma forma, leia sobre LLMs explicados e como eles se conectam com vector database em pipelines reais. Por fim, conheça os prompts eficientes que tiram o máximo dessa stack.

Qual o melhor vector database em 2026?
Não existe um melhor universal. Pinecone vence em zero infraestrutura, Qdrant em performance open source, Chroma em protótipos Python, pgvector pra quem já usa Postgres e Weaviate em casos enterprise multimodais. Escolha pelo caso de uso, não pelo hype.
pgvector é bom o suficiente pra produção?
Sim, em datasets abaixo de 50 milhões de vetores. Ele entrega latência de 5 a 8 ms com índice HNSW, custa o mesmo que seu Postgres atual e usa toda infraestrutura que você já tem. Acima dessa escala, considere Qdrant ou Pinecone.
Quanto custa rodar um vector database em produção?
Pra 10 milhões de vetores, Pinecone Serverless custa cerca de $70/mês, Qdrant Cloud $65, Weaviate $135 e pgvector em RDS $45. Em escalas maiores (100M+), Pinecone pode passar de $700/mês enquanto self-hosted fica abaixo de $100.
Posso usar embeddings sem vector database?
Pode, mas só faz sentido em datasets pequenos (até 10 mil documentos). Nesse caso, salve os vetores num array em memória ou JSON. Acima disso, o vector database vira obrigatório por causa do índice ANN, que acelera a busca em milhões de itens.
Qual a diferença entre vector database e database tradicional?
Bancos tradicionais buscam por valores exatos (igualdade, range, joins). Já um vector database busca por similaridade semântica entre vetores numéricos. Ambos coexistem na maioria das aplicações modernas: SQL pra dados estruturados, vector database pra busca por significado.