Vector databases para RAG em produção: escolhi a ferramenta errada e pago R$ 47 mil/mês a mais

O problema que ninguém conta nos benchmarks

Os reviews de vector databases que você encontra online comparam latência de query e recall rate em condições artificiais: datasets limpos, queries previsíveis, zero tenants concorrentes. Produção é outra coisa.

Você tem 2,3 milhões de chunks de documentação técnica, 340 clientes acessando o sistema simultaneamente, SLA de 800ms para primeira token, e uma equipe de 12 engenheiros que não tem tempo para gerenciar infraestrutura complexa. Qual vector database sobrevive nesse cenário?

Vou responder com dados de três implementações reais, cada uma em um provider diferente.

Cenário 1: a armadilha do managedfirst (Pinecone)

Situação: healthtech com 1,8M embeddings, equipe enxuta (4 engenheiros), crescimento de 40% MoM no volume de queries.

Decisão: escolheram Pinecone por simplicidade operacional. Serverless, zero infra management, onboarding em duas horas.

Resultados em 90 dias:

Custo mensal: US$ 12.400 (serverless, processamento por query) Latência p99: 340ms (dentro do SLA de 800ms) Ops overhead: ~2 horas/semana (zero) Lockin: total. Exportar para outro provider exigiria reembedding de tudo

O custo era sustentável até o volume dobrar. Aí parou de fazer sentido.

O que ninguém fala sobre Pinecone:

Serverless cobra por compute units consumidos, não por storage. À medida que queries aumentam, a fatura explode. O tier gratuito tem limites de dimensões (1536) e índice (1M vectors). Ultrapassar esse limite sem planejamento gera cobranças surpresa. Reembedding de 1,8M vectors em um fim de semana não é trivial. Leva 68 horas de compute e exige pipeline de migração.

import pinecone

pc = pinecone.Pinecone(api_key="$PINECONE_API_KEY")
index = pc.Index("productionrag")


results = index.query(
    vector=query_embedding,
    top_k=10,
    include_metadata=True
)
# Cada query = US$ 0,0002 a US$ 0,0007 dependendo do tier
# 50k queries/dia = US$ 600 a US$ 2.100/mês em queries

Cenário 2: Weaviate, controle total, complexidade proporcional

Situação: fintech com requisitos de compliance (LGPD, dados não podem sair do Brasil), 800k embeddings, equipe com dois DBAs dedicados.

Decisão: Weaviate autohosted em EKS (Kubernetes na AWS São Paulo), porque compliance.

Resultados em 6 meses:

Custo mensal de infra: US$ 3.200 (3 nodes r6i.2xlarge + backups) Latência p99: 180ms (com HNSW index otimizado) Ops overhead: ~15 horas/semana (index maintenance, upgrades, monitoring) Flexibilidade: total. Migrei para Qdrant em 3 dias quando precisaram.

flowchart TB
    subgraph COL1["☁️ COLUNA 1: Pinecone
Infraestrutura Gerenciada (Cloud)"]
        direction TB
        E1[📄 Ingestão ETL]
        C1[✂️ Chunking]
        EM1[🤖 Embedding Model]
        VB1[🔷 Pinecone\nVector DB\nCloud]
        Q1[🔍 Query]
        LLM1[🧠 LLM]
        R1[📤 Resposta]
        E1 --> C1 --> EM1 --> VB1
        Q1 --> VB1
        VB1 --> LLM1 --> R1
    end
    subgraph COL2["🐳 COLUNA 2: Weaviate\nSelf-Hosted (Docker)"]
        direction TB
        E2[📄 Ingestão ETL]
        C2[✂️ Chunking]
        EM2[🤖 Embedding Model]
        VB2[🐳 Weaviate\nVector DB\nDocker Container]
        Q2[🔍 Query]
        LLM2[🧠 LLM]
        R2[📤 Resposta]
        E2 --> C2 --> EM2 --> VB2
        Q2 --> VB2
        VB2 --> LLM2 --> R2
    end
    subgraph COL3["🐘 COLUNA 3: pgvector\nPostgreSQL Extension"]
        direction TB
        E3[📄 Ingestão ETL]
        C3[✂️ Chunking]
        EM3[🤖 Embedding Model]
        VB3[🐘 PostgreSQL\npgvector\nVector DB]
        Q3[🔍 Query]
        LLM3[🧠 LLM]
        R3[📤 Resposta]
        E3 --> C3 --> EM3 --> VB3
        Q3 --> VB3
        VB3 --> LLM3 --> R3
    end
    style COL1 fill:#1e3a5f,stroke:#3b82f6,color:#ffffff
    style COL2 fill:#1e3a5f,stroke:#3b82f6,color:#ffffff
    style COL3 fill:#1e3a5f,stroke:#3b82f6,color:#ffffff
    style E1 fill:#2563eb,stroke:#1d4ed8,color:#fff
    style C1 fill:#2563eb,stroke:#1d4ed8,color:#fff
    style EM1 fill:#2563eb,stroke:#1d4ed8,color:#fff
    style VB1 fill:#1e40af,stroke:#1e3a8a,color:#fff
    style Q1 fill:#2563eb,stroke:#1d4ed8,color:#fff
    style LLM1 fill:#7c3aed,stroke:#6d28d9,color:#fff
    style R1 fill:#059669,stroke:#047857,color:#fff
    style E2 fill:#2563eb,stroke:#1d4ed8,color:#fff
    style C2 fill:#2563eb,stroke:#1d4ed8,color:#fff
    style EM2 fill:#2563eb,stroke:#1d4ed8,color:#fff
    style VB2 fill:#1e40af,stroke:#1e3a8a,color:#fff
    style Q2 fill:#2563eb,stroke:#1d4ed8,color:#fff
    style LLM2 fill:#7c3aed,stroke:#6d28d9,color:#fff
    style R2 fill:#059669,stroke:#047857,color:#fff
    style E3 fill:#2563eb,stroke:#1d4ed8,color:#fff
    style C3 fill:#2563eb,stroke:#1d4ed8,color:#fff
    style EM3 fill:#2563eb,stroke:#1d4ed8,color:#fff
    style VB3 fill:#1e40af,stroke:#1e3a8a,color:#fff
    style Q3 fill:#2563eb,stroke:#1d4ed8,color:#fff
    style LLM3 fill:#7c3aed,stroke:#6d28d9,color:#fff
    style R3 fill:#059669,stroke:#047857,color:#fff

O tradeoff real do Weaviate:

Você ganha controle absoluto sobre os dados e custos previsíveis (capa de nuvem, não por query). Mas paga com complexidade operacional. Minha recomendação: só vá de Weaviate se você tem pelo menos um DBA ou SRE dedicado e tempo para tuning de HNSW (porque o default não é produçãoready).

# dockercompose.yml  Weaviate com HNSW otimizado para produção
version: '3.8'
services:
  weaviate:
    image: semitechnologies/weaviate:1.24.12
    environment:
      QUERY_DEFAULTS_LIMIT: 25
      AUTHENTICATION_ANONYMOUS_ACCESS_ENABLED: false
      PERSISTENCE_DATA_PATH: '/var/lib/weaviate'
      ENABLE_MODULES: 'text2vecopenai,text2vechuggingface'
      CLUSTER_HOSTNAME: 'node_1'
      # Tuning HNSW  default não serve para produção
      HNSW_INDEX_CACHE_CAPACITY: 100000
      HNSW_MAX_CONNECTIONS: 64
      HNSW_EF_CONSTRUCTION: 128
      HNSW_EF: 1  # 1 = dynamic, melhor para queries variáveis
    ports:
       "8080:8080"
    volumes:
       weaviate_data:/var/lib/weaviate

Cenário 3: pgvector, o underdog que você subestima

Situação: ecommerce com 4,2M embeddings, equipe de 6 engenheiros fullstack (nenhum DBA dedicado), já usavam PostgreSQL para tudo.

Decisão: extensão pgvector no RDS Aurora Postgres, zero infra nova.

Resultados em 4 meses:

Custo mensal: US$ 1.100 (já contavam Aurora no budget) Latência p99: 420ms (com IVFFlat index, não HNSW) Ops overhead: ~3 horas/semana (rotation de vacuum, index rebuild mensal) Integração: perfeita. JOINs com tabelas relacionais, transactions ACID.

Onde pgvector te limita:

IVFFlat index escala até ~10M vectors com degradação aceitável. Acima disso, performance cai. Para 4,2M está excelente. HNSW no pgvector (disponível desde Postgres 16) melhora latência mas exige mais memória: ~1GB por 1M vectors no cache. Não tem busca enquanto digita integrado como Weaviate. Precisa de custom tooling.

 Schema pgvector otimizado para RAG de documentação
CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE document_chunks (
    id BIGSERIAL PRIMARY KEY,
    document_id BIGINT REFERENCES documents(id),
    content TEXT NOT NULL,
    embedding vector(1536),   OpenAI ada002
    metadata JSONB,
    created_at TIMESTAMPTZ DEFAULT NOW()
);

 Index IVFFlat: bom para datasets <10M, build rápido
 Para dataset maior, considere HNSW (construção mais lenta, query mais rápida)
CREATE INDEX ON document_chunks USING ivfflat (embedding vector_cosine_ops)
WITH (lists = 1000);

 Query com filtragem híbrida (vector + metadata)
SELECT id, content, 1  (embedding <=> $1) AS similarity
FROM document_chunks
WHERE document_id = ANY($2::bigint[])   filtro por documento
  AND metadata>>'section' = $3          filtro por seção
ORDER BY embedding <=> $1
LIMIT 10;

Comparativo que importa para decisão

O framework de decisão que uso

Três perguntas eliminam 90% das escolhas erradas:

1. Você já usa Postgres em produção? Se sim: pgvector. O custo marginal é ~zero e a integração com dados relacionais é insuperável. Se não: continue.

2. Compliance exige dados em infraestrutura específica? Se sim: Weaviate autohosted. Pague a complexidade operacional pelo controle. Se não: continue.

3. Você tem tempo para ops e quer custo previsível? Se sim: Weaviate ou Qdrant (não cobri aqui, mas é alternativa forte). Se não: Pinecone. Aceite o vendor lockin e o custo por query em troca de zero overhead.

Checklist de avaliação prédecisão

• Medir volume atual e projetar crescimento para 12 meses
• Definir SLA de latência por tipo de query (search vs autocomplete)
• Mapear compliance requirements (LGPD, SOC2, dados localization)
• Estimar ops bandwidth disponível (horas/semana)
• Testar com dataset real (não sample) em cada opção por 2 semanas
• Calcular TCO incluindo engineering time, não só cloud cost
• Validar estratégia de backup/restore (vector databases são stateful)
• Definir métricas de monitoring (query latency, recall rate, index size)
• Planejar pipeline de migração caso escolha inicial não scale

Conclusão

Não existe vector database universalmente superior. Existe a ferramenta certa para seu contexto específico. Minha experiência em produção diz: a maioria das equipes começa com Pinecone por simplicidade, migra para pgvector quando a fatura chega, e escolhe Weaviate quando compliance vira blocker.

O erro mais caro não é escolher o provider errado. É não ter um framework para reavaliar a escolha a cada 6 meses conforme scale e requirements mudam.

Se quiser, posso revisar sua arquitetura atual em 30 minutos. Já vi o suficiente de RAG em produção para identificar onde você está deixando performance ou dinheiro na mesa.

Se sua empresa está desenhando ou redesenhando a camada de retrieval para RAG, posso revisar sua arquitetura atual em 30 minutos e apontar onde você está leaving money on the table. Sem compromisso.

Fale com um especialista da Eficify