Timescale apresenta pg_vectorsearch, extensão com índice que promete superar o pgvector

A pg_vectorsearch, da Timescale, traz o índice PRISM: compatível com tabelas pgvector existentes e, segundo o projeto, mais rápido que IVFFlat e HNSW tanto na consulta quanto na criação do índice.

Quem roda busca por similaridade em PostgreSQL↳PostgreSQL11 conteúdosPostgreSQL via SSL com GolangData · abr 20195 itens legais sobre data types do PostgreSQLData · mar 20195 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data → hoje provavelmente usa o pgvector, com seus índices IVFFlat ou HNSW. A Timescale, empresa por trás da extensão de séries temporais TimescaleDB, publicou no GitHub a pg_vectorsearch, uma nova extensão que promete ser mais rápida que os dois em consultas e também na construção do índice. O projeto está em código aberto, sob licença PostgreSQL.

O ponto central é o índice PRISM (Partitioned Routing Index for Similarity Matching). Segundo a documentação do projeto, ele é "conceitualmente parecido com o IVFFlat do pgvector", mas construído com técnicas mais recentes de quantização, roteamento e particionamento, implementadas em C.

Como o PRISM organiza a busca

O PRISM usa uma árvore hierárquica de centróides para particionar os vetores em clusters, mantida aquecida na memória com o buffer cache do próprio Postgres. Os vetores são quantizados com RaBitQ e armazenados em listas de posting com um layout de página otimizado para computação de distância via SIMD (AVX2, AVX512, NEON).

A sequência de uma consulta, conforme descrita no README, segue quatro passos:

1. Percorre a árvore de centróides para achar os clusters mais próximos (via buffer cache)
2. Varre as listas de posting em busca de candidatos (buffer cache, I/O assíncrono)
3. Aplica a filtragem em duas etapas do RaBitQ: estimativa, limite de erro, rerank
4. Faz o rerank de precisão total a partir da tabela e retorna os k vizinhos mais próximos

O ganho de velocidade vem principalmente do passo 3: a codificação RaBitQ carrega limites de erro teóricos (descritos no paper RaBitQ, do SIGMOD 2024) que permitem descartar, de forma matematicamente segura, vetores que não podem ser vizinhos mais próximos. Com isso, menos candidatos precisam do rerank caro contra os vetores de precisão total.

O diferencial prático: não precisa trocar de tabela

Para quem já tem uma base rodando com pgvector, o ponto mais relevante não é a arquitetura interna, e sim a compatibilidade. A pg_vectorsearch pode ser instalada ao lado do pgvector e construir um índice PRISM diretamente sobre colunas vector ou halfvec já existentes, sem reescrever ou copiar a tabela.

O README traz o exemplo de migração completo:

-- A tabela que você já tem, com índice HNSW do pgvector
CREATE EXTENSION vector;

CREATE TABLE documents (
 id bigserial PRIMARY KEY,
 body text,
 embedding vector(384)
);
CREATE INDEX documents_embedding_hnsw
 ON documents USING hnsw (embedding vector_l2_ops);

-- Instala a pg_vectorsearch e constrói o índice sobre a coluna existente
CREATE INDEX documents_embedding_prism
 ON documents USING prism (embedding vec32_l2_ops);

Depois de validar o ganho com EXPLAIN (COSTS OFF), basta derrubar o índice antigo com DROP INDEX documents_embedding_hnsw. As consultas continuam usando os mesmos operadores (<->, <#>, <=>), então nenhuma query do código precisa mudar.

Para quem está começando do zero, a extensão também oferece tipos nativos, vec32 (float32) e vec16 (float16, que reduz pela metade o espaço ocupado pelos vetores na tabela), sem depender do pgvector:

CREATE EXTENSION pg_vectorsearch;

CREATE TABLE items (
 id serial PRIMARY KEY,
 embedding vec32(3) STORAGE PLAIN
);

CREATE INDEX ON items USING prism (embedding vec32_l2_ops);

-- 0 = automático (~0.95 de recall). Sobe para mais recall, desce para mais velocidade.
SET prism.nprobe = 40;

Os números que o projeto apresenta

Segundo a Timescale, comparado ao HNSW (índice baseado em grafo, hoje tido como referência de recall no pgvector), o PRISM é mais rápido no mesmo nível de recall em um dataset de 100 milhões de vetores, rodando numa instância com um quarto da memória que o HNSW exigiria. Não há, no material publicado, uma tabela detalhada de latência ou throughput por configuração; o claim fica no texto do README, sem link direto para um relatório de benchmark completo.

Para quem avalia a troca, isso importa: o número de memória é o mais concreto da comparação, porque HNSW é conhecido por ser voraz em RAM justamente por manter o grafo inteiro acessível. Reduzir essa pegada a um quarto, se confirmado em produção, muda a conta de custo de infraestrutura para quem roda busca vetorial em escala, não só a latência de consulta.

Por que ainda não é hora de migrar em produção

O próprio projeto classifica seu status como alpha, com o aviso explícito: "destinado a testes, não a produção". Atualizações entre pré-lançamentos podem não ser compatíveis entre si, e a recomendação atual, em caso de upgrade, é derrubar e recriar a extensão e seus índices.

Também há requisitos de ambiente que pesam na decisão de testar agora ou esperar:

• PostgreSQL 18 ou superior, com headers de desenvolvimento
• Compilador GNU C11 (GCC 11+ ou Clang 14+)
• Sistema de build Meson
• CBLAS como dependência opcional, para acelerar a codificação RaBitQ

Quem está em PostgreSQL 15, 16 ou 17 em produção, cenário comum no Brasil, simplesmente não consegue testar sem migrar antes o banco para a versão 18. Isso empurra a avaliação da pg_vectorsearch para depois (ou em paralelo com) a própria atualização do Postgres, o que naturalmente adia o tipo de teste de carga que validaria os números de memória e latência citados no README.

O que fica em aberto

A manutenção contínua também é um ponto a observar: como as listas de posting só crescem com as inserções e nunca se dividem sozinhas, a extensão depende de uma rotina chamada prism_rebalance para reequilibrar listas que ficaram grandes demais, fora do fluxo automático de um REINDEX. O guia de manutenção do próprio projeto reconhece limitações atuais nesse mecanismo, sem detalhar quais.

Fica em aberto, ainda, um benchmark público e reproduzível com metodologia clara (dataset, hardware, parâmetros de recall) que sustente a comparação com IVFFlat e HNSW fora do texto do README. A Timescale já mantém outra extensão de busca vetorial para Postgres, a pgvectorscale, baseada em DiskANN, o que situa a pg_vectorsearch como uma terceira aposta da empresa na mesma área, não a primeira. Para quem administra bancos com embeddings em produção, o caminho razoável por ora é acompanhar o changelog do projeto e reservar um ambiente de teste, não trocar o índice da base viva.

Fonte: Hacker News