Vector DBs em 2026: Qdrant, Weaviate, Pinecone, pgvector
⏱ 13 min·⭐ 65 XP
Pré-requisitos (0/1)0%
- ⬜🚢 Semantic search em produção: indexing, sharding, freshness(Search & Information Retrieval Profundo)
Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.
O cenário em 2026
Mercado consolidou: pgvector para start, Qdrant para self-host sério, Pinecone para serverless gerenciado. Weaviate ainda forte em casos com schema rico. LanceDB para embedded. Milvus em deployments massivos. Escolha errada vira migration dolorosa.
Comparativo definitivo
| DB | Modelo | Scale típico | Forte em | Fraco em |
|---|---|---|---|---|
| pgvector | Postgres extension | ≤10-50M | SQL filters, ops zero (já tem PG) | >100M, latência alta |
| Qdrant | Self-host / cloud | 100M+ | Rust speed, on-the-fly filtering | Aprender API |
| Weaviate | Self-host / cloud | 100M+ | GraphQL, multi-modal, vetorização built-in | Mais opinionated |
| Pinecone | Serverless SaaS | Ilimitado | Zero ops, latência consistente | Custo em escala alta, vendor lock |
| LanceDB | Embedded | ~10M local | Single binary, multi-modal, offline | Não centralizado |
| Milvus | Self-host / Zilliz cloud | B+ vetores | Massive scale | Complexidade ops |
| Chroma | Embedded / self-host | ~10M | DX amigável Python | Maturidade em escala |
| Vespa | Self-host | B+ vetores | Hybrid lexical+vector + ranking complex | Curva de aprendizado |
DBpgvector
ModeloPostgres extension
Scale típico≤10-50M
Forte emSQL filters, ops zero (já tem PG)
Fraco em>100M, latência alta
DBQdrant
ModeloSelf-host / cloud
Scale típico100M+
Forte emRust speed, on-the-fly filtering
Fraco emAprender API
DBWeaviate
ModeloSelf-host / cloud
Scale típico100M+
Forte emGraphQL, multi-modal, vetorização built-in
Fraco emMais opinionated
DBPinecone
ModeloServerless SaaS
Scale típicoIlimitado
Forte emZero ops, latência consistente
Fraco emCusto em escala alta, vendor lock
DBLanceDB
ModeloEmbedded
Scale típico~10M local
Forte emSingle binary, multi-modal, offline
Fraco emNão centralizado
DBMilvus
ModeloSelf-host / Zilliz cloud
Scale típicoB+ vetores
Forte emMassive scale
Fraco emComplexidade ops
DBChroma
ModeloEmbedded / self-host
Scale típico~10M
Forte emDX amigável Python
Fraco emMaturidade em escala
DBVespa
ModeloSelf-host
Scale típicoB+ vetores
Forte emHybrid lexical+vector + ranking complex
Fraco emCurva de aprendizado
Quiz rápido
Qual é a diferença essencial entre os dois algoritmos de índice aproximado mais usados?
Algoritmos por dentro
HNSW (Hierarchical Navigable Small World)Grafo multi-camada, O(log N), high recall, ~4-8 bytes/dim overhead
IVF (Inverted File Index)Cluster k-means; busca em cluster próximo. Memória eficiente, recall menor
PQ (Product Quantization)Compressão por sub-vector quantization. 32x memory savings com pequena perda
DiskANN (Microsoft)SSD-aware, single-machine billions de vetores
ScaNN (Google)Anisotropic vector quantization, alta accuracy
📋 Qual escolher?
✓ Comece com pgvector
Já tem Postgres. Zero ops adicional. HNSW nativo bom até 10M. Migre quando comprovar limite.
Alt: Qdrant — Quando passar de 50M ou precisar filtering complex on-the-fly
Alt: Pinecone — Time pequeno, sem appetite ops, custo OK
Alt: LanceDB — App desktop/edge/CLI
Alt: Milvus — B+ vetores em produção
Perguntas frequentes
❓ Como escolher banco vetorial em 2026?
Pelo modelo de operação antes do recurso: gerenciado quando você não quer operar índice, auto-hospedado quando custo em escala manda ou o dado não pode sair, e Postgres com extensão quando o volume cabe e você já o opera. Os recursos convergiram; operação e custo é o que diferencia.
❓ O que medir ao comparar bancos vetoriais?
Recall a um limite de latência, com o SEU volume e a SUA dimensão — mais custo por milhão de vetores e desempenho de filtro por metadado. Comparar por vazão sem fixar recall é o erro típico: é fácil ser rápido devolvendo resultado pior.
❓ Filtro por metadado importa tanto assim?
Importa mais do que a maioria espera: buscar só nos documentos que aquele usuário pode ver, ou só no período relevante, é requisito comum — e o desempenho do filtro combinado com busca vetorial varia enormemente entre implementações. É o critério que decide na prática.
Fixando
Volume e operação
Postgres + vetorcabe na instância, uma peça a menos
Busca gerenciadahíbrido de fábrica
Banco dedicadoescala e recurso de índice
Índice
Grafo hierárquicorecall alto, custa memória
Partição por agrupamentoeconômico, precisa treinar
Requisito que decide
Filtro por metadadosó o que o usuário pode ver
Recall a uma latênciano SEU volume
- → no mesmo lugar
- → varia muito
- → medir
- → medir
- Banco de dados
- Analytics
- Conceito de arquitetura
- Segurança e identidade
Os recursos convergiram; o que diferencia é operação, custo por milhão de vetores e desempenho do filtro por metadado. Escolher por vazão em benchmark sintético é escolher pelo número que menos importa.
- Comece pelo que você já opera. Se o volume cabe e você tem Postgres, a extensão de vetor é uma peça a menos, com transação e filtro por metadado no mesmo lugar.
- O índice é uma troca entre memória e recall. Grafo hierárquico dá recall alto e custa memória; partição por agrupamento é econômica e sensível ao número de partições varridas.
- Filtro por metadado é o critério que decide na prática. Buscar só no que aquele usuário pode ver é requisito comum, e o desempenho disso varia enormemente entre implementações.
- Medir recall a uma latência fixa. É fácil ser rápido devolvendo resultado pior. Comparar vazão sem fixar recall é o erro típico de avaliação de banco vetorial.
- Trocar de modelo de embedding é reindexar tudo. É a decisão mais difícil de reverter — mais que a de banco. Vetores de modelos diferentes vivem em espaços incomparáveis.
Quiz rápido
O que precisa ser medido ao ajustar um índice aproximado?
Quiz rápido
Quando um banco vetorial dedicado supera claramente a extensão num banco relacional?
Terminou de ler?
Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.
Próximos passos sugeridos
Temas deste módulo
Discussão
Carregando comentários…