Um banco de dados vetorial guarda embeddings e responde consultas de vizinhos mais próximos com índices aproximados (HNSW, IVF etc.). Pinecone, Qdrant, Weaviate, Milvus e pgvector (PostgreSQL) são opções comuns.
Ele não substitui o banco relacional: complementa. Você filtra por metadados (tenant, data, tipo) e depois ranqueia por similaridade semântica. Hybrid search (vetor + BM25) costuma superar só vetor em muitos corpora.
Critérios de escolha
Latência, suporte a filtros, custo operacional, se já existe Postgres no stack (pgvector evita serviço extra) e facilidade de backup/restore. Para protótipo, Chroma ou pgvector bastam; para multi-tenant em escala, avalie gerenciados ou clusters dedicados.
Em ambientes reais, Banco de Dados Vetorial aparece junto de decisões de arquitetura, custo e operação. Vale documentar no runbook do time: quando usar, quando evitar, métricas de saúde e o que fazer quando falha. Links internos do hub (comandos, erros, comparativos) ajudam a fechar o ciclo entre teoria e prática.
Antes de adotar em produção, monte um teste com dados reais do seu contexto — benchmarks genéricos raramente capturam latência, volume e casos de borda do seu sistema. Prefira evoluir em fatias pequenas, com observabilidade e critério de rollback claros.
Se você está desenhando a solução pela primeira vez, comece pelo caminho mais simples que atende o requisito e só adicione complexidade (mais serviços, mais abstrações) quando a dor for medida, não imaginada.