Vector database, ou banco de dados vetorial, é o sistema que armazena embeddings — as representações numéricas de significado — e encontra os mais parecidos com uma consulta em milissegundos, mesmo entre milhões de registros. É a peça de infraestrutura que sustenta busca semântica e a etapa de recuperação do RAG. A pergunta prática que quase todo projeto enfrenta no início é se vale contratar um banco vetorial dedicado ou usar o que já se tem. E há um dado que reenquadra a decisão: o PostgreSQL é o banco de dados mais usado do mercado, com 55,6% entre cerca de 49 mil respondentes de uma pesquisa independente de 2025 — e nenhum banco vetorial dedicado aparece na lista de bancos dessa mesma pesquisa. A extensão vetorial do Postgres resolve a maioria dos casos de martech.
⚠️ “Preciso de banco vetorial dedicado” — e o mito espelhado
Existem comparações medindo pgvector — a extensão do Postgres — contra bancos dedicados. E aqui é preciso um aviso que muda como ler os números: essas comparações são publicadas por fornecedores, e cada um mede a métrica em que ganha.
- Um teste com 1 milhão de embeddings de 1.536 dimensões, publicado por uma empresa que vende Postgres gerenciado, mostra o pgvector entregando cerca de 1.370 consultas por segundo a 98% de acurácia, contra faixas bem menores de um concorrente dedicado em configuração de custo equiparado.
- Outro teste, publicado por uma empresa que vende uma extensão do Postgres, mostra o concorrente dedicado com latência 39% a 48% melhor nos percentis altos — perdendo em vazão agregada, mas ganhando em tempo de resposta individual.
Os dois estão medindo coisas diferentes e ambos têm interesse no resultado. Nenhum é veredito. O que essa contradição prova é que a pergunta é legítima — e que o mito espelhado, “pgvector sempre resolve”, também não se sustenta.
O limite técnico que não é comercial
Existe um critério de decisão que independe de quem patrocina o teste: o índice de busca precisa caber na memória RAM. É isso que determina o ponto de virada.
| Escala | Recomendação |
|---|---|
| Até ~10 milhões de vetores | Postgres com extensão vetorial — elimina um sistema do stack |
| Acima disso | Avaliar dedicado — a 50 milhões × 768 dimensões, o índice passa de 150 GB de RAM |
Para dimensionar: uma operação de marketing com catálogo de produtos, histórico de atendimento e base de conteúdo costuma ficar entre centenas de milhares e poucos milhões de trechos. Isso está confortavelmente na primeira faixa.
Sobre tamanho de mercado, uma nota: circulam projeções de US$ 3,2 a 3,65 bilhões para 2026, com taxas de crescimento entre 19% e 27%. Vêm de relatórios pagos, com metodologia atrás de paywall e divergência grande entre si — por isso não os tratamos como dado verificado.
O que isso muda na prática
Três orientações para quem está montando a infraestrutura:
- Comece no banco que você já opera. Se a empresa já tem Postgres — e as chances são altas —, ativar a extensão vetorial elimina um sistema inteiro de operação, monitoramento e custo. Migre depois, se a escala exigir.
- Dimensione pela memória, não pelo marketing. Calcule quantos vetores você terá e quanto o índice ocupará. Esse número decide, não a categoria do produto.
- Desconfie de comparação publicada por quem vende. Rode o seu próprio teste com o seu volume real e as suas consultas reais. É a única medição sem conflito de interesse.
Um sistema a menos no stack costuma valer mais que ganho marginal de desempenho — especialmente numa equipe de marketing, onde não há time dedicado de infraestrutura para manter mais um componente de pé.
A conta completa de infraestrutura própria está no guia de self-host.
Fontes
- Stack Overflow Developer Survey 2025 — ~49 mil respondentes, fonte independente
- ANN-Benchmarks — benchmark aberto de busca por vizinhos aproximados
- pgvector vs Pinecone — patrocinado: publicado por fornecedor de Postgres
- pgvector vs Qdrant — patrocinado: publicado por fornecedor de extensão Postgres
Leitura das fontes em 17/08/2026.