Guia para desenvolvedores Postgres: tradeoffs em índices vetoriais

O guia atual não é só sobre escolher um índice: é sobre projetar um sistema de busca vetorial dentro de um banco de dados relacional. O HNSW, embora padrão para leitura intensiva, exige 2, 5× mais memória que o IVFFlat e pode levar horas para construir em datasets de meios milhão de vetores, como mostrou benchmark de maio de 2026 com 500 mil embeddings de 384 dimensões (4065 s vs 128 s). Já o IVFFlat troca recall por velocidade de construção e menor footprint, mas sua acurácia depende criticamente do número de clusters (lists) e da quantidade de partições consultadas (probes). Quando os índices ultrapassam a RAM, o StreamingDiskANN do pgvectorscale entra em cena: ele mantém o grafo em disco, usa pré-busca inteligente para SSDs NVMe e incorpora SBQ (Quantização Binária Estatística), permitindo 99% de recall em 50 milhões de vetores com latência p95 28× menor que o Pinecone. A busca híbrida com BM25 não é um extra, é uma correção estrutural: ela recupera correspondências exatas que a semântica perde, e o RRF (Reciprocal Rank Fusion) é a forma prática de fundir os dois scores no SQL.

A escolha do índice não é técnica isolada, mas parte de uma arquitetura de dados. Um incidente real em maio de 2026 expôs o custo oculto de separar metadados (em PostgreSQL) e embeddings (em outro serviço): latência de API saltou para 9 segundos e o Kafka acumulou 1,8 milhão de eventos em backlog. Consolidar tudo no PostgreSQL com pgvector + pgvectorscale reduz infraestrutura em até 58%, elimina ETL e garante ACID, algo que bancos vetoriais dedicados não oferecem nativamente.

Em menos de um ano, o ecossistema evoluiu de 'PostgreSQL com pgvector para pequenos casos' para 'PostgreSQL como camada unificada de dados e IA em produção'. A versão 0.8.2 do pgvector (fevereiro de 2026) corrigiu estouro de buffer em construções paralelas de HNSW e reduziu uso de memória e WAL, problemas reais que travavam implantações em escala. Já o pgvectorscale, lançado em novembro de 2024, deixou de ser uma promessa e virou solução validada: benchmarks de março de 2026 mostram 471 QPS com 99% de recall em 50 milhões de vetores, superando o Qdrant em 11,4×. Isso muda o cenário descrito na cobertura anterior sobre CockroachDB: enquanto o C-SPANN foi construído para contornar limitações de arquitetura distribuída, o PostgreSQL agora resolve escala com extensões nativas, sem precisar reinventar o indexador.

Porque equipes de dados estão migrando de 'banco de dados + banco vetorial' para 'banco de dados com capacidade vetorial nativa'. Isso simplifica pipelines, reduz falhas de consistência e corta custos operacionais. Para marketing orientado por IA, citado na cobertura anterior, isso significa que workflows com ENUMs de estado e JSONB de contexto podem agora incluir buscas semânticas em tempo real, sem sair do mesmo banco, sem duplicar dados. Não é só conveniência: é governança prática. Um índice mal projetado não só atrasa queries, compromete a qualidade dos resultados de RAG, afeta a confiança do usuário em assistentes técnicos e gera retrabalho em pipelines de indexação de imagens, como descrito em outra cobertura CEVIU.