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

O 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. Segundo a página oficial de pricing do Pinecone (verificado em agosto/2026), o plano Standard parte de US$ 50/mês de mínimo mais consumo (US$ 0,33/GB de storage, US$ 4 por milhão de write units e US$ 16 por milhão de read units). Além disso, há um tier Starter gratuito com até 2 GB. 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 cobra por recursos provisionados, em torno de US$ 57/mês por GB de RAM.

Chroma: protótipos em Python

O 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

O 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 US$ 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.

Menções honrosas 2026: Turbopuffer e LanceDB

Dois nomes novos ganharam tração forte em 2026. O Turbopuffer nasceu pra rodar busca vetorial direto em object storage (S3), o que derruba o custo de armazenamento pra cerca de US$ 0,02/GB. Em vez de manter tudo em RAM, ele usa um cache de três níveis (DRAM, NVMe e S3). Por isso, escala pra trilhões de vetores com custo baixo, embora seja managed-only e sem free tier.

Já o LanceDB aposta no caminho embedded e multimodal. Ele guarda texto, imagem, áudio e vetores num mesmo schema Arrow, usando o formato aberto Lance (evolução do Parquet). Da mesma forma que o Chroma, roda dentro do processo da aplicação. Portanto, vale a pena pra quem trabalha com dados multimodais na borda ou em pipelines de ML locais.

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 Self-host? Free tier? Licença
Pinecone ~45 ms a partir de ~US$ 50/mês (Standard) + consumo Managed only Não Sim (Starter, 2 GB) Proprietary
Qdrant ~12 ms ~US$ 57/mês por GB de RAM (Cloud) Self-host + cloud Sim Sim (cluster 1 GB) Apache 2.0
Chroma ~30 ms Grátis (embedded) In-process Sim Sim (OSS) Apache 2.0
pgvector ~5-8 ms (HNSW) ~US$ 45/mês (RDS) Postgres extension Sim Sim (OSS) PostgreSQL
Weaviate ~20 ms ~US$ 135/mês (Cloud) Self-host + cloud Sim Sim (sandbox) BSD-3
Turbopuffer ~10 ms (warm) mínimo US$ 64/mês + storage ~US$ 0,02/GB Managed (S3) Não Não Proprietary
LanceDB ~15 ms Grátis (OSS embedded) Embedded + cloud Sim Sim (OSS) Apache 2.0

Dados de benchmarks públicos (VectorView, LeanOps, Supabase) e docs oficiais. Custos verificados em agosto/2026.

Veja uma observação importante. Custos crescem de forma diferente em cada vector database. Por exemplo, o consumo do Pinecone Standard cresce com read/write units e storage, o que encarece cargas de leitura intensa. Já pgvector e Qdrant self-hosted ficam abaixo de US$ 100/mês em escalas maiores. Por isso, o custo virou um critério decisivo conforme você escala.

Publicidade

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. Para a maioria dos projetos novos, recomendamos começar com pgvector: ele reaproveita o Postgres que a equipe já opera e evita mais um serviço na stack. 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.

Bash
# 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.

Bash
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, o Pinecone Standard parte de US$ 50/mês de mínimo mais consumo, Qdrant Cloud fica em torno de US$ 57/mês por GB de RAM, Weaviate perto de US$ 135/mês e pgvector em RDS cerca de US$ 45/mês. Em escalas maiores (100M+), opções self-hosted como Qdrant e pgvector ficam bem abaixo de US$ 100/mês.
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.
O Pinecone é grátis?
Sim, o Pinecone tem um tier Starter gratuito com até 2 GB de storage, 2 milhões de write units e 1 milhão de read units por mês, sem exigir cartão de crédito e sem mínimo mensal. Ele não inclui SLA e serve pra prototipar. Pra produção, o plano Standard parte de US$ 50/mês de mínimo mais consumo.

Publicidade