pgvector

pgvector é a extensão do PostgreSQL que adiciona suporte a vetores de embeddings, tornando Postgres uma vector database competente. Em 2026, é uma das opções mais populares para times que já usam Postgres e querem adicionar capacidades vetoriais sem novo banco.

Por que pgvector é tão popular:

• Postgres: você já roda. Não precisa adicionar nova infra.
• Maturidade: extensão estável, em produção em muitas empresas.
• Transações ACID: vetores junto com dados relacionais em transação atômica.
• JOINs: combinar busca vetorial com queries SQL ricas.
• Backup/restore: usa pg_dump como o resto.
• Open source: sem vendor lock-in.

Recursos em 2026 (versão 0.8.6, setembro de 2026):

• Tipos vector com armazenamento de até 16.000 dimensões.
• Índices HNSW e IVFFlat com limite de 2.000 dimensões por vetor indexado.
• Índices: HNSW (rápido para query), IVFFlat (rápido para insert).
• Operadores de distância: <-> (L2), <#> (dot product), <=> (cosine).
• Halfvec: vetores em meia precisão (16 bits) para economia.
• Bit vectors: para hashes binários.
• Sparse vectors: para vetores esparsos.

Armazenamento e índice têm limites diferentes. O tipo vector aceita até 16.000 dimensões para armazenar, mas os índices HNSW e IVFFlat indexam no máximo 2.000 dimensões por vetor; acima disso, use redução de dimensionalidade (como halfvec) ou uma alternativa dedicada. Detalhes na documentação oficial: https://github.com/pgvector/pgvector

Setup básico:

CREATE EXTENSION vector;

CREATE TABLE documentos ( id BIGSERIAL PRIMARY KEY, texto TEXT, embedding vector(1536), -- dimensão do OpenAI text-embedding-3-small metadata JSONB, criado_em TIMESTAMPTZ DEFAULT NOW() );

CREATE INDEX ON documentos USING hnsw (embedding vector_cosine_ops);

-- Buscar 5 mais similares SELECT texto, metadata FROM documentos WHERE metadata->>'categoria' = 'manual' ORDER BY embedding <=> '[0.1, 0.2, ...]'::vector LIMIT 5; ```

Quando pgvector é boa escolha:

• Já usa Postgres: redundante adicionar outro DB.
• Tamanho moderado: até ~10-50M vetores.
• Queries híbridas: filtros SQL complexos + similaridade.
• Compliance: total controle, dados onde você quer.

Quando ir para alternativas:

• >100M vetores: pgvector escala mas dedicados (Qdrant, Milvus) são mais eficientes.
• Latência crítica < 10ms: dedicados são mais rápidos.
• Multi-modal nativo (text + image embeddings com features avançadas): Weaviate, Pinecone têm mais.

Hosting:

• Self-hosted: Postgres em VPS, Docker, Kubernetes.
• Supabase: pgvector incluído, fácil de começar.
• Neon: serverless Postgres com pgvector.
• AWS RDS, Azure DB for Postgres, GCP Cloud SQL: pgvector disponível.
• Crunchy Data, Tembo: managed Postgres especializado.

Tuning:

• HNSW vs IVFFlat: HNSW maior performance de query, mais lento para indexar.
• m e ef_construction (HNSW): tradeoffs entre qualidade e custo.
• Probes (IVFFlat): mais probes = melhor recall, mais lento.
• Vacuum e autovacuum: vital para performance estável.

Para o profissional brasileiro:

• Stack típica brasileira: Next.js + Postgres + pgvector + OpenAI embeddings + Claude/GPT para geração. Combina tudo numa infra simples.
• Hosting nacional: Magalu Cloud, IBM Cloud, AWS São Paulo, Postgres + pgvector no Brasil.
• Setup em horas: muito mais rápido que adotar Pinecone para projetos médios.

Em 2026, pgvector é "SQLite do mundo vetorial", não o mais poderoso, mas o mais acessível e suficiente para 80% dos casos. Para muitas empresas brasileiras, é a primeira (e às vezes única) vector DB que precisam.