Escolhendo um vector database sem virar refém de hype

Um dos maiores erros em projetos de IA é escolher vector database sem fazer pergunta simples: "Preciso mesmo disso?"

A resposta é: na maioria dos casos, não.

A gente vê muito startup saindo do zero direto pra Pinecone ou Qdrant. Depois descobrem que Postgres + pgvector resolveria 90% do problema por 10% do custo.

Este post é pra você entender quando vector database de verdade importa e quando é over-engineering.

O que um vector database realmente faz?

Um vector database:

1. Armazena vetores (embeddings) de alta dimensão (1024-3072 dims)
2. Indexa pra busca rápida via estrutura otimizada (HNSW, IVF, Annoy)
3. Busca vizinhos próximos (ANN — Approximate Nearest Neighbors)
4. Filtra por metadata (tag, timestamp, categoria)
5. Suporta batch operations em escala

Isso é diferente de banco tradicional porque:

• SQL é lento em busca multi-dimensional
• Você quer aproximado rápido, não exato lento
• Volume é diferente (milhões de vetores é comum)

Exemplo:

-- PostgreSQL tradicional: LENTO
SELECT * FROM documentos 
WHERE titulo LIKE '%python%'
ORDER BY similarity(embedding, query_embedding) DESC
LIMIT 10;

-- Pode levar 5-30 segundos (sem índice, full scan)

-- Com pgvector + índice HNSW: RÁPIDO
SELECT * FROM documentos 
WHERE embedding <-> query_embedding 
ORDER BY embedding <-> query_embedding
LIMIT 10;

-- Leva 50-200ms

A diferença é estrutura de índice. pgvector consegue isso. Postgres puro não.

Critérios de escolha

1. Escala: quantos vetores?

Volume	Melhor opção
< 100k vetores	Postgres + pgvector
100k - 1M	Postgres + pgvector ou Qdrant
1M - 10M	Qdrant, Weaviate, Milvus
10M+	Pinecone, Elasticsearch, Milvus distribuído

Postgres escala bem até ~1M vetores com pgvector + bom índice. Depois começa a ficar lento.

2. Latência SLA

SLA: p95 < 100ms

├─ In-memory (Redis Vector): 10-30ms
├─ Local SSD (Qdrant, Chroma): 30-100ms
├─ Postgres + pgvector: 50-200ms (depende índice)
├─ Managed (Pinecone): 100-300ms (rede)
└─ Elasticsearch: 200-500ms

Quer p95 < 50ms? Qdrant local é melhor que Pinecone managed. Quer managed? Pinecone é mais rápido que Postgres remoto.

3. Filtragem de metadata

A gente quer buscar vetores e filtrar:

"Busque documentos similares a query_embedding 
 MAS APENAS de categoria='urgent' 
 E data > '2026-04-01'"

Qualidade de suporte:

• Postgres: Estruturado, suporta tudo (JSONB, índices compostos)
• Qdrant: Ótimo, payload filtering nativo
• Pinecone: Metadata filtering recente, antes era ruim
• Weaviate: Filtering via Graphql, ok
• Chroma: Básico

Se metadata filtering é crítico, Postgres ou Qdrant.

4. Operacional: quem gerencia?

Postgres: Você (ou RDS/Supabase)
Qdrant: Você (ou Qdrant Cloud)
Pinecone: Pinecone (serverless, menos operação)
Chroma: Você (simples, mas local)

Quer serverless e não quer pensar? Pinecone. Quer control e entender o stack? Postgres ou Qdrant.

5. Custo

Cenário: 1M embeddings de 1536 dims, 10 queries/seg, 30 dias

Sistema	Armazenamento	Queries	Total/mês
Postgres (RDS)	$30	$15	$45
Qdrant Cloud	$100	free	$100
Pinecone Starter	free	$0.1/1M	~$259
Milvus (self-hosted)	$50	$0	$50

Postgres vence em custo puro. Pinecone sai caro em queries.

6. Ecosystem

Llama Index / Langchain: suporta tudo (bom abstraction)
OpenAI SDK: Pinecone é mencionado
Vercel AI: Supabase Vector (Postgres) é recomendado
MLOps: Milvus, Weaviate têm mais community

Se você já usa LangChain, toda opção funciona.

Vector databases em 2026

Postgres + pgvector (recomendação padrão)

-- Setup
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE documents (
    id BIGSERIAL PRIMARY KEY,
    content TEXT,
    embedding vector(1536),
    category VARCHAR(50),
    created_at TIMESTAMP
);

-- Índice
CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops);

-- Query
SELECT id, content 
FROM documents 
WHERE category = 'urgent'
ORDER BY embedding <-> '[0.1, 0.2, ..., 0.9]'::vector
LIMIT 10;

Vantagens:

• Você já conhece SQL
• Runs em RDS, Supabase, self-hosted
• Metadata filtering é SQL puro (flexível)
• Custo previsível
• Backups, replicação, clustering padrão

Desvantagens:

• Max ~1M vetores antes de ficar lento
• Índice HNSW é novo, menos maduro
• Não é otimizado para puro vector search (tem SQL overhead)

Quando usar: < 1M vetores, metadata complexa, budget apertado.

Qdrant (open source, managed disponível)

from qdrant_client import QdrantClient

client = QdrantClient("localhost", port=6333)

# Criar collection
client.create_collection(
    collection_name="documents",
    vectors_config=VectorParams(size=1536, distance=Distance.COSINE)
)

# Inserir com metadata
client.upsert(
    collection_name="documents",
    points=[
        Point(
            id=1,
            vector=[0.1, 0.2, ..., 0.9],
            payload={"category": "urgent", "source": "email"}
        )
    ]
)

# Buscar com filtro
results = client.search(
    collection_name="documents",
    query_vector=[0.1, 0.2, ..., 0.9],
    query_filter=models.Filter(
        must=[
            models.HasIdCondition(has_id=[1, 2, 3])
        ],
        must_not=[
            models.HasIdCondition(has_id=[4, 5])
        ]
    ),
    limit=10
)

Vantagens:

• Otimizado pra vectors (mais rápido que Postgres)
• Metadata filtering é nativo e bem-feito
• Open source + managed (flexível)
• Escalável (clusters distribuídos)

Desvantagens:

• Precisa gerenciar (Você ou Qdrant Cloud)
• Mais caro que Postgres puro
• SQL queries diretas não funcionam (Graphql ou API)

Quando usar: 1M+ vetores, latência importante, metadata filtering complexo.

Pinecone (managed, serverless)

from pinecone import Pinecone

pc = Pinecone(api_key="...")
index = pc.Index("documents")

# Upsert
index.upsert(vectors=[
    ("doc-1", [0.1, 0.2, ..., 0.9], {"category": "urgent"}),
])

# Query
results = index.query(
    vector=[0.1, 0.2, ..., 0.9],
    top_k=10,
    filter={"category": {"$eq": "urgent"}}
)

Vantagens:

• Zero operacional (managed)
• Serverless (paga por uso)
• Global distribution (CDN-style)
• Bom pra demo/MVP

Desvantagens:

• Caro em queries (P-1 plan: $0.1 por 1M ops)
• Menos controle
• Vendor lock-in

Quando usar: Startup em MVP, não quer operação, budget pra pagar premium.

Chroma (open source, embedded)

import chromadb

client = chromadb.Client()
collection = client.create_collection(name="documents")

collection.add(
    ids=["doc1", "doc2"],
    embeddings=[[0.1, 0.2, ...], [0.3, 0.4, ...]],
    metadatas=[{"source": "pdf"}, {"source": "email"}]
)

results = collection.query(
    query_embeddings=[[0.1, 0.2, ...]],
    n_results=10
)

Vantagens:

• Embed em Python, SQLite storage
• Zero setup
• Bom pra prototyping

Desvantagens:

• Não escala bem (< 100k vetores)
• Sem filtering sofisticado
• Local only (não é distributed)

Quando usar: Prototipos, Jupyter notebooks, demos.

Weaviate (open source, GraphQL)

import weaviate

client = weaviate.Client("http://localhost:8080")

# Criar schema
client.schema.create_class({
    "class": "Document",
    "vectorizer": "none",
    "properties": [
        {"name": "content", "dataType": ["text"]},
        {"name": "category", "dataType": ["text"]}
    ]
})

# Insert
client.data_object.create(
    class_name="Document",
    data_object={
        "content": "...",
        "category": "urgent"
    },
    vector=[0.1, 0.2, ...]
)

# Query via GraphQL
query = """
{
    Get {
        Document(where: {
            path: ["category"],
            operator: Equal,
            valueString: "urgent"
        }, limit: 10) {
            content
        }
    }
}
"""

Vantagens:

• GraphQL é moderno
• Bom pra schema complexos
• Distributed

Desvantagens:

• Curva de aprendizado (GraphQL)
• Performance não é melhor que Qdrant

Quando usar: Já usa GraphQL, quer open source, metadata muito complexa.

Milvus (open source, distributed, não managed)

from pymilvus import Collection

collection = Collection("documents")

# Insert
data = [
    [i for i in range(1, 100)],  # IDs
    [[random() for _ in range(1536)] for _ in range(100)]  # embeddings
]
collection.insert(data)

# Query
search_params = {"metric_type": "L2", "params": {"nprobe": 32}}
results = collection.search(
    query_vector,
    "embedding",
    search_params,
    limit=10
)

Vantagens:

• Open source
• Escalável (clusters distribuídos)
• Suporta 10B+ vetores

Desvantagens:

• Complexo de operar
• Sem managed commercial
• Menos community que Pinecone/Qdrant

Quando usar: Scale muito grande, on-prem, quer open source.

Matriz de decisão

1. Volume de vetores?
   < 100k → Postgres
   100k-1M → Postgres ou Qdrant
   > 1M → Qdrant, Pinecone, Milvus

2. Latência importante?
   Sim → Qdrant, Redis Vector
   Não → Postgres, Pinecone

3. Quer gerenciar infraestrutura?
   Não → Pinecone
   Sim → Qdrant, Postgres, Milvus

4. Metadata filtering complexo?
   Sim → Postgres, Qdrant
   Não → Qualquer um

5. Budget?
   Apertado → Postgres
   Normal → Qdrant
   Alto → Pinecone

Armadilhas de migração

Se começou com Postgres e precisa migrar pra Qdrant depois:

Problema: Embeddings em Postgres, código em LangChain com abstração de Postgres.

# Código atual (Postgres)
from langchain.vectorstores import PGVector
vs = PGVector.from_documents(docs, embeddings, ...)

# Quer migrar pra Qdrant
from langchain.vectorstores import Qdrant
vs = Qdrant.from_documents(docs, embeddings, ...)

# Precisa:
# 1. Exportar vetores de Postgres
# 2. Importar em Qdrant
# 3. Mudar 2-3 linhas de código

Bom: LangChain abstrai bem, migração é fácil.

Ruim: Metadata pode estar em schema diferente. Postgres JSONB vs Qdrant payload.

Recomendação: Use abstração de dia 1 (LangChain, Llamaindex). Depois trocar backend é um refactor menor.

Começar: Postgres até prova de conceito

Passo 1: Postgres + pgvector (RDS, Supabase, ou docker local) Passo 2: Índice HNSW simples, teste latência Passo 3: Se < 100ms, keep. Se > 500ms, considere Qdrant Passo 4: Se volume cresce > 1M, avalie migração

Isso funciona pra 80% dos casos. E você economiza meses em DevOps.

A gente na Alienhub tem clientes grandes em Qdrant, Pinecone, Postgres. Escolha depende do problema. Mas a maioria sai ganhando começando simples.

Se você está pensando em vector database e não sabe por onde começar, bora conversa. A gente ajuda a separar hype de necessidade real.