O fim dos bancos de dados vetoriais: pgvector esta matando Pinecone e Weaviate?

O que é um banco de dados vetorial

Um banco de dados vetorial e um sistema de armazenamento especializado em guardar e buscar embeddings - vetores numéricos de alta dimensão que representam o significado semântico de textos, imagens ou outros dados. Em vez de buscar por palavras exatas, você busca por similaridade: documentos com significado parecido ficam próximos no espaço vetorial.

Essa tecnologia virou o coracaoo das aplicações com RAG (Retrieval-Augmented Generation), onde um LLM precisa buscar informações relevantes antes de responder. Em vez de jogar tudo no contexto do modelo (caro e limitado), você armazena os documentos como vetores e recupera apenas os mais relevantes para cada pergunta.

Nos últimos 3 anos, surgiram dezenas de produtos dedicados exclusivamente a isso: Pinecone, Weaviate, Qdrant, Chroma, Milvus. Cada um prometia ser a solução definitiva para busca semântica em escala. Agora, em 2026, o mercado esta questionando se esses produtos separados ainda fazem sentido.

Por que os vetoriais standalone estão perdendo terraca

A lógica era simples: bancos de dados de uso geral (PostgreSQL, SQLite, MySQL) não foram projetados para operações de similaridade em vetores de 1536 dimensões. Então criou-se uma categoria nova, otimizada só para isso.

O problema e que o argumento ficou menos solido com o tempo. A extensão pgvector para o PostgreSQL chegou em 2021 e evoluiu rapidamente. Em 2023 já suportava índices HNSW (Hierarchical Navigable Small World), o mesmo algoritmo usado pelos bancos vetoriais especializados. Em 2024, o desempenho em benchmarks independentes já era comparável ao Pinecone para a maioria dos casos de uso reais.

Em paralelo, o SQLite-vec trouxe busca vetorial para o banco de dados mais usado do mundo, o que abriu RAG até para aplicações mobile e edge. A Cloudflare integrou vetores ao D1 (seu banco SQLite na edge). A Supabase lançou suporte nativo a vetores via pgvector. O MongoDB lançou Atlas Vector Search. Cada plataforma de banco de dados que você já usa foi adicionando esse recurso.

pgvector: o principal substituto na prática

O pgvector e uma extensão open source para o PostgreSQL. Você instala com uma linha e passa a ter um novo tipo de coluna (vector(1536)) e operadores de similaridade (<=> para cosseno, <-> para L2, <#> para produto interno).

Criar uma tabela com suporte a vetores no PostgreSQL fica assim:

-- Habilitar extensão
CREATE EXTENSION IF NOT EXISTS vector;

-- Tabela com coluna vetorial
CREATE TABLE documentos (
  id BIGSERIAL PRIMARY KEY,
  conteúdo TEXT,
  embedding vector(1536)
);

-- Índice HNSW para busca rápida
CREATE ÍNDEX ON documentos
  USING hnsw (embedding vector_cosine_ops);

-- Buscar os 5 mais similares
SELECT conteúdo, embedding <=> '[0.1, 0.2, ...]'::vector AS distancia
FROM documentos
ORDER BY distancia
LIMIT 5;

Com o índice HNSW, o pgvector consegue fazer buscas de similaridade em menos de 10ms em coleções com mais de 1 milhão de vetores, dependendo das configurações de hardware. Para a maioria das aplicações de RAG, isso é mais que suficiente.

Como começar com pgvector no seu projeto

Se você usa Supabase, o pgvector já vem ativo. Basta criar a tabela e usar. Se você usa um PostgreSQL próprio ou da AWS/GCP/Azure, a instalação varia:

# Ubuntu/Debian
sudo apt install PostgreSQL-16-pgvector

# Ou via Docker (imagem oficial com pgvector)
Docker run -e POSTGRES_PASSWORD=senha \
  -p 5432:5432 \
  pgvector/pgvector:pg16

Em Python, a biblioteca mais usada e o psycopg2 ou psycopg3 com o adapter do pgvector:

pip install pgvector psycopg2-binary openai

import psycopg2
from pgvector.psycopg2 import register_vector
from openai import OpenAI

conn = psycopg2.connect("PostgreSQL://...")
register_vector(conn)

client = OpenAI()

def gerar_embedding(texto: str) -> list:
    resp = client.embeddings.create(
        model="text-embedding-3-small",
        input=texto
    )
    return resp.data[0].embedding

# Inserir documento
embedding = gerar_embedding("Como configurar pgvector")
with conn.cursor() as cur:
    cur.execute(
        "INSERT INTO documentos (conteúdo, embedding) VALUES (%s, %s)",
        ("Como configurar pgvector", embedding)
    )
conn.commit()

Exemplo prático: RAG simples com pgvector

Um sistema de RAG com pgvector em produção tem basicamente 3 etapas: indexar os documentos, buscar os relevantes e passar para o LLM. Aqui esta o fluxo completo de busca:

def buscar_contexto(pergunta: str, limite: int = 5) -> list:
    embedding_pergunta = gerar_embedding(pergunta)
    
    with conn.cursor() as cur:
        cur.execute("""
            SELECT conteúdo, 
                   1 - (embedding <=> %s::vector) AS similaridade
            FROM documentos
            ORDER BY embedding <=> %s::vector
            LIMIT %s
        """, (embedding_pergunta, embedding_pergunta, limite))
        
        return [
            {"conteúdo": row[0], "similaridade": row[1]}
            for row in cur.fetchall()
            if row[1] > 0.7  # filtrar baixa relevância
        ]

# Usar no RAG
contexto = buscar_contexto("Como instalar pgvector?")
contexto_texto = "\n".join([r["conteúdo"] for r in contexto])

resposta = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[
        {"role": "system", "content": f"Contexto:\n{contexto_texto}"},
        {"role": "user", "content": "Como instalar pgvector?"}
    ]
)

Isso e tudo que você precisa para um RAG funcional em produção. Sem infraestrutura nova, sem mais uma conta para gerenciar, sem mais uma API para chamar.

Comparação: pgvector vs bancos vetoriais standalone

pgvector (integrado ao PostgreSQL): zero custo adicional de infraestrutura, transações ACID, joins com dados relacionais, backup junto com o resto do banco, operações SQL familiares. A desvantagem e que o PostgreSQL precisa ser escalado junto, e para coleções muito grandes (mais de 100 milhões de vetores) o desempenho pode cair sem hardware dedicado.

Pinecone: SaaS gerenciado, escalabilidade automática, excelente para coleções de bilhões de vetores com latência consistente. A desvantagem e o custo (pode ser significativo em escala) e a dependência de um serviço externo. Ideal para quem precisa de escala acima de 50 milhões de vetores sem querer gerenciar infraestrutura.

Qdrant: open source, self-hosted ou cloud, excelente performance com filtros complexos (metadata filtering). Boa escolha quando você precisa de filtros muito específicos combinados com busca vetorial. Mais configurável que o pgvector para casos avançados.

Pontos positivos e limitações do pgvector

O que funciona bem: integrar busca vetorial ao banco que você já tem e o beneficio principal. Você pode fazer joins, usar transações, aplicar filtros complexos com SQL e usar as mesmas ferramentas de backup e monitoramento que já usa. O custo zero e outro beneficio importante para projetos pequenos e médios.

O que limita: para coleções acima de 50 milhões de vetores, o pgvector precisa de configuração cuidadosa de hardware e índices para manter a performance. Acima de 500 milhões de vetores, bancos especializados tendem a ser mais eficientes. A limitação de 2000 dimensões também pode ser um problema com modelos de embedding de última geração.

Outro ponto: o pgvector não tem uma interface gráfica nativa para explorar vetores ou debugar buscas. Ferramentas como o Supabase Studio ajudam, mas não chegam ao nível de visualizações que produtos como o Weaviate oferecem out-of-the-box.

Casos de uso reais

Startup com MVP de chatbot interno: pgvector e a escolha certa. Você já tem PostgreSQL, adiciona a extensão em 5 minutos, e tem RAG funcionando sem custo adicional. Pode crescer com ele até centenas de milhares de documentos sem problema.

Plataforma SaaS com multi-tenancy: pgvector funciona bem aqui. O filtro por tenant e uma WHERE clause SQL simples, e o HNSW ainda e usado dentro do subset filtrado. Alternativa: Qdrant com payload filtering se o volume for muito alto.

Aplicação de busca semântica com bilhões de itens: aqui os bancos especializados ainda tem vantagem. Pinecone ou um Qdrant em cluster dedicado escalam melhor que um PostgreSQL nessa faixa de volume.

Aplicação mobile ou edge com RAG local: SQLite-vec e a opcao mais prática. Roda dentro do app, sem dependência de rede, tamanho mínimo.

Dicas e boas práticas

Vale a pena trocar Pinecone por pgvector?

Para a maioria dos projetos: sim. Se você tem menos de 10 milhões de vetores, já usa PostgreSQL e não precisa de funcionalidades muito específicas de um banco vetorial dedicado, a migração para pgvector economiza dinheiro, simplifica a infraestrutura e não sacrifica performance relevante para os usuários finais.

Quando manter o banco vetorial standalone: volumes acima de 50 milhões de vetores, necessidade de latência muito baixa com alta concorrência, ou uso intenso de funcionalidades avançadas como filtragem por metadata em grande escala. Nesse caso, Pinecone ou Qdrant ainda fazem sentido.

O próximo passo e instalar a extensão pgvector no seu PostgreSQL e fazer o teste: CREATE EXTENSION vector;. Leva 30 segundos e você já pode começar a experimentar. A documentação oficial em GitHub.com/pgvector/pgvector e excelente.