Banco de Dados Vetorial: O Guia Completo para IA e Busca Semântica [2026]

Banco de dados vetorial é o tipo de infraestrutura que ninguém comentava em reunião até 2023 e que hoje sustenta praticamente todo produto sério com IA: chatbots que respondem com base nos documentos da empresa, buscas que entendem intenção em vez de palavras exatas, sistemas de recomendação que captam gosto e contexto. Na Marfin, a primeira vez que precisamos de um foi para dar memória de longo prazo a um assistente interno, e desde então ele virou peça padrão do nosso stack de IA.

O problema que ele resolve é simples de enunciar e difícil de resolver com banco tradicional. Um Postgres ou MySQL encontra registros que batem exatamente com o que você pediu: um email, um ID, uma palavra no título. Só que "como cancelar minha assinatura" e "quero encerrar meu plano" são frases sem nenhuma palavra relevante em comum, e qualquer sistema de atendimento decente precisa entender que as duas pedem a mesma coisa. Busca por palavra-chave falha nesse cenário. Busca semântica, alimentada por um banco de dados vetorial, acerta.

Neste guia, nós explicamos o que é um banco de dados vetorial, como a busca semântica funciona por baixo do capô, quando faz sentido usar um, quais são as principais opções de 2026 com preços atualizados, e como montamos nosso primeiro projeto na prática. Se você está construindo qualquer coisa com IA generativa, esse conhecimento vai economizar semanas de tentativa e erro.

O que é um banco de dados vetorial

Um banco de dados vetorial é um sistema de armazenamento especializado em guardar e consultar vetores, listas longas de números que representam o significado de um conteúdo. Cada texto, imagem ou áudio que entra no sistema passa antes por um modelo de embedding, que o converte em um vetor de centenas ou milhares de dimensões. O banco guarda esses vetores junto com metadados e, na hora da consulta, encontra os vetores mais próximos do vetor da sua pergunta.

A palavra decisiva aqui é "próximos". Em um banco relacional, a pergunta é "quais registros são iguais a isso?". Em um banco de dados vetorial, a pergunta vira "quais registros são parecidos com isso?". Essa mudança de igualdade para similaridade é o que destrava busca semântica, recomendação e memória para agentes de IA.

Vale dizer o que ele não é: um substituto do seu banco principal. Nós continuamos guardando usuários, pedidos e assinaturas no Postgres. O banco vetorial entra ao lado, cuidando exclusivamente da camada de significado. Em muitos casos, como veremos adiante, ele pode inclusive morar dentro do próprio Postgres via extensão, o que simplifica bastante a vida de quem está começando.

O que são embeddings e como eles capturam significado

Embedding é a representação numérica que um modelo de IA gera para um conteúdo. O modelo text-embedding-3-small da OpenAI, por exemplo, transforma qualquer texto em um vetor de 1.536 números. O Voyage e o Cohere têm modelos próprios, com dimensões e pontos fortes diferentes. O que todos têm em comum: textos com significados parecidos geram vetores geometricamente próximos.

Isso soa abstrato até você ver funcionando. O vetor de "cachorro" fica perto do vetor de "cão" e de "labrador", razoavelmente perto de "gato", e longe de "planilha de Excel". O modelo aprendeu essas relações lendo quantidades absurdas de texto durante o treinamento, e o resultado é um espaço matemático onde distância significa diferença de sentido.

Na prática, o fluxo é sempre o mesmo. Nós pegamos os documentos, quebramos em pedaços menores (os famosos chunks), geramos um embedding para cada pedaço e gravamos tudo no banco de dados vetorial. Quando o usuário faz uma pergunta, geramos o embedding da pergunta com o mesmo modelo e pedimos ao banco os dez pedaços mais próximos. Esses pedaços viram contexto para o LLM responder. Esse fluxo tem nome, RAG, e nós explicamos ele em detalhe no nosso guia sobre o que é RAG.

Um detalhe que muita gente aprende do jeito difícil: o modelo de embedding da indexação e o da consulta precisam ser o mesmo. Vetores de modelos diferentes vivem em espaços incompatíveis, e misturar os dois gera resultados aleatórios sem nenhuma mensagem de erro. Nós já perdemos uma tarde inteira de debugging por causa disso.

Como funciona a busca semântica em um banco de dados vetorial

A busca semântica em um banco de dados vetorial se resume a um problema de geometria: dado o vetor da consulta, encontrar os K vetores mais próximos entre milhões armazenados. O nome técnico é kNN, k-nearest neighbors. Calcular a distância exata contra cada vetor do banco funciona com dez mil registros e desmorona com dez milhões, então todos os bancos sérios usam busca aproximada, a ANN, que troca uma fração mínima de precisão por consultas em milissegundos.

O algoritmo dominante em 2026 continua sendo o HNSW, Hierarchical Navigable Small World. Ele organiza os vetores em um grafo de múltiplas camadas, onde as camadas de cima permitem saltos longos e as de baixo refinam a busca localmente. É como achar um endereço olhando primeiro o mapa do país, depois o da cidade, depois o do bairro. Pinecone, Qdrant, Weaviate e pgvector implementam variações desse mesmo algoritmo, e as diferenças de qualidade entre eles são bem menores do que o marketing sugere.

Métricas de distância e o que escolher

Para dizer que dois vetores são "próximos", o banco precisa de uma métrica. As três mais comuns são similaridade de cosseno, que compara o ângulo entre os vetores e é o padrão para texto, produto interno (dot product), preferido quando os vetores já vêm normalizados, e distância euclidiana, mais comum em visão computacional. Na dúvida, use cosseno: é o que a documentação de quase todo modelo de embedding recomenda e o que nós usamos em todos os nossos projetos de texto.

Outro conceito que aparece cedo é o filtro de metadados. Busca vetorial pura retorna os chunks mais parecidos do banco inteiro, mas quase sempre você quer restringir: só documentos daquele cliente, só artigos publicados depois de 2025, só conteúdo em português. Os bancos modernos combinam o filtro estruturado com a busca vetorial em uma única consulta, e a forma como cada um faz isso (pré-filtro ou pós-filtro) impacta diretamente a qualidade dos resultados. O Qdrant é particularmente bom nesse quesito, com filtragem integrada ao próprio índice HNSW.

Também vale conhecer a busca híbrida, que combina o ranking vetorial com busca por palavra-chave tradicional (BM25) e funde os dois resultados. Para consultas com nomes próprios, códigos de produto ou siglas, o componente de palavra-chave segura casos em que o embedding sozinho escorrega. Weaviate e Qdrant oferecem isso nativo, e no Postgres dá para combinar pgvector com o full-text search que já vem de fábrica.

Quando usar um banco de dados vetorial (e quando não usar)

O caso de uso número um, disparado, é RAG. Qualquer produto que responde perguntas com base em uma base de conhecimento própria, documentação interna, contratos, tickets antigos, artigos do blog, precisa de um banco de dados vetorial para recuperar o contexto certo antes de chamar o LLM. É o que alimenta os chatbots de atendimento com IA que de fato resolvem problemas em vez de responder genérico.

O segundo caso forte é busca semântica em produto. E-commerces que entendem "presente para quem gosta de café" sem ter nenhum produto com esse nome, plataformas de conteúdo que sugerem artigos pelo assunto e não pela tag, ferramentas internas que encontram aquele documento que você lembra vagamente. O terceiro é recomendação: itens com embeddings próximos aos que o usuário consumiu são candidatos naturais para a próxima sugestão. E o quarto, cada vez mais relevante em 2026, é memória de agentes. Agentes de IA que rodam por semanas precisam lembrar de interações antigas, e a forma padrão de implementar isso é gravar cada interação como embedding e recuperar as relevantes a cada novo turno. Quem conecta agentes a ferramentas externas via MCP esbarra nesse padrão o tempo todo.

Agora, o outro lado. Se sua base tem menos de dez mil documentos e as consultas são raras, você provavelmente nem precisa de infraestrutura dedicada: dá para guardar os embeddings em uma coluna comum e calcular similaridade na aplicação, ou usar o pgvector sem índice nenhum. Se seu problema é busca exata (SKU, CPF, número de pedido), banco relacional resolve melhor e mais barato. E se você só quer que o modelo responda sobre conhecimento público geral, o próprio LLM já dá conta sem recuperação nenhuma. Nós já vimos startup montando cluster de Milvus para buscar em 200 PDFs, e esse é o tipo de complexidade que atrasa produto sem devolver nada em troca.

Principais bancos de dados vetoriais em 2026

O mercado amadureceu e se consolidou em torno de meia dúzia de nomes. Nós testamos todos os abaixo em projetos reais ou provas de conceito, e a boa notícia é que para 90% dos casos qualquer um deles entrega. A escolha acaba sendo mais sobre operação e custo do que sobre capacidade técnica.

pgvector (Supabase): por onde nós recomendamos começar

O pgvector é uma extensão open source do PostgreSQL que adiciona o tipo vector e índices HNSW ao banco que você provavelmente já usa. No Supabase, que é o backend padrão dos nossos projetos de vibe coding, ele vem habilitado com um clique, junto com auth, storage e edge functions. Para quem está decidindo a base do projeto, nosso comparativo Supabase vs Firebase explica por que o Postgres gerenciado ganhou esse espaço.

A vantagem operacional é enorme: seus embeddings moram ao lado dos seus dados relacionais, na mesma transação, com o mesmo backup, protegidos pelas mesmas políticas de RLS. Um join entre a tabela de chunks e a tabela de documentos do cliente é uma query SQL comum. Nenhum banco dedicado oferece essa integração. O limite aparece na casa das dezenas de milhões de vetores com alta concorrência, escala que a imensa maioria dos produtos brasileiros nunca vai atingir.

Pinecone: o gerenciado mais conhecido

O Pinecone popularizou a categoria e continua sendo a opção serverless mais polida. Você não gerencia nada: cria um índice, manda vetores pela API e paga pelo uso. A latência é consistentemente baixa e a documentação é referência. O contraponto é o custo em escala e o lock-in, já que ele é fechado e exclusivamente cloud. Nós o vemos como escolha sólida para equipes que querem zero operação e têm orçamento para isso.

Qdrant: o favorito de quem gosta de open source

Escrito em Rust, open source, com filtragem de metadados excelente e busca híbrida nativa. Dá para rodar em Docker localmente, exatamente igual à versão de produção, o que torna o desenvolvimento muito confortável. O Qdrant Cloud oferece cluster gratuito de 1 GB que aguenta protótipos de verdade. Dos bancos dedicados, é o que nós mais usamos quando o pgvector deixa de ser suficiente.

Weaviate, Chroma e Milvus

O Weaviate é open source, forte em busca híbrida e traz módulos que geram embeddings automaticamente na ingestão, o que reduz código. O Chroma é o queridinho da prototipagem: roda embutido no seu processo Python ou TypeScript com duas linhas, perfeito para experimentos, com o Chroma Cloud cobrindo produção leve. O Milvus, com o serviço gerenciado Zilliz Cloud, é a artilharia pesada para bilhões de vetores, mais comum em empresas grandes do que em startups.

Preços e planos

Os valores abaixo são de junho de 2026 e podem variar com uso, então confirme na página de preços de cada um antes de decidir.

Uma observação sobre custo total: o banco costuma ser a parte barata da conta. O que pesa é a geração de embeddings (cobrada por token pelos provedores de modelo) e as chamadas ao LLM na hora de responder. Nos nossos projetos, o banco vetorial raramente passa de 15% do custo da feature de IA. Antes de otimizar a infraestrutura de busca, olhe para o tamanho dos chunks e para quantos deles você injeta em cada prompt.

Como nós montamos um projeto com banco de dados vetorial na prática

Nosso fluxo padrão na Marfin começa no Supabase. Criamos o projeto, habilitamos o pgvector no painel de extensões e definimos uma tabela de documentos com uma coluna embedding vector(1536), além das colunas de metadados que os filtros vão precisar: origem, idioma, data, cliente. Um índice HNSW na coluna de embedding e uma função SQL de match por similaridade de cosseno completam a base. Tudo isso são menos de 30 linhas de SQL.

A implementação em si nós fazemos com Claude Code, a ferramenta de programação com IA que mais usamos aqui. Descrevemos o pipeline (ler os documentos, quebrar em chunks de 500 tokens com overlap, gerar embeddings, gravar no banco, expor um endpoint de busca) e ele escreve, testa e ajusta o código de ponta a ponta no terminal. Para os refinamentos do dia a dia dentro do projeto, usamos o Cursor AI, que é a nossa IDE de building. Quem ainda está entrando nesse modo de trabalhar encontra o caminho completo no nosso guia sobre o que é vibe coding.

Duas decisões definem a qualidade do resultado mais do que qualquer outra. A primeira é o chunking: pedaços grandes demais diluem o significado e trazem contexto irrelevante, pedaços pequenos demais perdem o fio da meada. Nosso ponto de partida é 400 a 600 tokens com 10% de sobreposição, respeitando fronteiras de parágrafo e de seção, e ajustamos a partir de testes reais. A segunda é a avaliação: antes de considerar o sistema pronto, montamos um conjunto de 30 a 50 perguntas reais com as respostas esperadas e medimos se os chunks corretos aparecem no top 5 da busca. Sem esse teste, qualquer mudança de modelo ou de parâmetro vira chute.

O erro mais comum que vemos por aí é pular direto para a ferramenta mais sofisticada. Comece com pgvector no plano gratuito do Supabase, valide que a busca retorna o que deveria, coloque usuários reais em cima e só então discuta migração. Trocar de banco vetorial depois é um trabalho de horas, porque o grosso do esforço (chunking, embeddings, avaliação) é portável. Escolher errado no início e sobre-engenheirar custa semanas.

7 dicas para trabalhar com banco de dados vetorial

1. Fixe o modelo de embedding e registre a versão. Todos os vetores do banco precisam vir do mesmo modelo, e trocar de modelo significa reindexar tudo. Grave o nome e a versão do modelo nos metadados de cada registro para nunca ter dúvida.

2. Trate o chunking como produto, e não como detalhe. A qualidade das respostas do seu RAG nasce na forma como você quebra os documentos. Teste tamanhos diferentes com perguntas reais antes de congelar a estratégia.

3. Use filtros de metadados desde o primeiro dia. Origem, data, idioma e dono do documento devem ser colunas filtráveis. Adicionar isso depois exige reprocessar a base inteira, e cinco minutos de modelagem agora evitam esse retrabalho.

4. Monte um conjunto de avaliação antes de otimizar. Trinta perguntas reais com resposta esperada bastam para medir recall da busca. Sem essa régua, você nunca sabe se uma mudança melhorou ou piorou o sistema.

5. Considere busca híbrida quando houver nomes e códigos. Embeddings escorregam em SKUs, siglas e nomes próprios raros. Combinar busca vetorial com BM25 cobre esses casos com pouco esforço adicional.

6. Comece pequeno e local. Chroma embutido ou Qdrant em Docker permitem desenvolver sem depender de cloud nem gastar um centavo. Suba para o serviço gerenciado quando o protótipo provar valor.

7. Monitore o custo dos embeddings, e não só o do banco. Reindexações frequentes de bases grandes queimam orçamento em silêncio. Processe de forma incremental, apenas o que mudou, usando hash do conteúdo para detectar alterações.

Banco de dados vetorial deixou de ser assunto de time de ML e virou conhecimento básico para qualquer pessoa construindo produto com IA, do founder técnico ao profissional de marketing que automatiza conteúdo. A barreira de entrada em 2026 é a mais baixa da história: pgvector gratuito no Supabase, Claude Code escrevendo o pipeline, e uma tarde de trabalho entre a ideia e a primeira busca semântica funcionando. Nós passamos por essa curva, e a diferença entre produtos de IA que impressionam e os que frustram está quase sempre na qualidade da recuperação de contexto. Agora você sabe por onde começar a construir a sua.

Leia também:

• O que é RAG e como funciona na prática
• Supabase vs Firebase: qual backend escolher
• MCP: o que é o Model Context Protocol
• IA generativa para negócios
• Chatbot com IA para atendimento: como criar o seu
• Prompt engineering: guia completo em português
• Tech stack 2026: as ferramentas que toda startup brasileira precisa
• Claude vs ChatGPT vs Gemini: qual usar
• n8n tutorial: automações com IA na prática
• SEO para IA: como aparecer nas respostas dos LLMs