Tiger Data lança pg_vectorsearch, extensão open source que reduz memória da busca vetorial no PostgreSQL

A Tiger Data, empresa anteriormente conhecida como Timescale e criadora do TimescaleDB, lançou em 7 de novembro de 2026 o pg_vectorsearch, uma extensão open source↳Open source71 conteúdosComo o Open Source Está Liberando o Poder da Automação para TodosDev (Back & Front) · out 2025Código aberto: programadores criam software da NASA sem saberDev (Back & Front) · abr 2021N8N: O que é a ferramenta open source que está revolucionando a automação em TI?Dev (Back & Front) · dez 2025Ver tudo em Dev (Back & Front) → de busca vetorial para 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 →. A novidade, ainda em fase alpha, chega com um índice chamado PRISM, pensado como alternativa ao HNSW usado pelo pgvector, a extensão mais popular do ecossistema para esse tipo de busca. Segundo o anúncio coberto pelo InfoQ, o objetivo é claro: reduzir a infraestrutura necessária para lidar com grandes volumes de vetores diretamente dentro do banco.

Para quem constrói aplicações de busca semântica ou RAG↳RAG6 conteúdosTécnica RAG com a biblioteca Langchain: tutorial para aplicar agoraData · jun 2024Como avaliar LLMs, RAG e Agentes de IA: Teoria e prática.AI · abr 2026RAG Não É Memória: O Problema Real dos Agentes de IAAI · mai 2026Ver tudo em AI → (Retrieval-Augmented Generation) no Brasil, isso tem peso real. Rodar um índice vetorial pesado costuma significar subir uma instância maior, às vezes em dólar, só para aguentar o índice em memória. Uma extensão que promete o mesmo resultado com menos RAM ataca diretamente esse custo.

Como funciona o índice PRISM

O pgvector resolve busca por similaridade com o HNSW (Hierarchical Navigable Small World), um algoritmo de grafo que conecta cada vetor aos seus vizinhos mais próximos. É rápido, mas o grafo inteiro precisa ficar acessível com baixa latência, o que pressiona a memória.

O PRISM troca o grafo por particionamento e compressão. Em vez de montar uma rede de conexões, ele agrupa vetores parecidos em partições e guarda cada uma como uma lista comprimida, compactada em páginas do próprio banco. Os engenheiros da Tiger Data descrevem a diferença assim:

O PRISM traz uma abordagem baseada em partições para o PostgreSQL, similar à usada por sistemas de busca vetorial dedicados mais recentes. Em vez de conectar cada vetor aos seus vizinhos em um grafo, o PRISM agrupa vetores similares em partições e os armazena como uma lista em formato comprimido, densamente compactada em páginas do banco de dados.

Erik Nordström, Matvey Arye e Noah Hein, engenheiros e product marketing na Tiger DataPRISM brings a partition-based approach to PostgreSQL, similar to the approach used by newer dedicated vector search systems. Instead of connecting every vector to its neighbors in a graph, PRISM groups similar vectors into partitions and stores them as a list in a compressed format that is densely packed into database pages.

Na prática, uma busca não percorre o grafo inteiro: ela identifica as partições relevantes e varre sequencialmente os vetores comprimidos dentro delas, evitando acesso aleatório caro à memória ou ao disco. Michael Freedman, cofundador e CTO da Tiger Data, detalhou a arquitetura em artigo publicado no LinkedIn: o índice combina clustering hierárquico para reduzir o espaço de busca, vetores comprimidos para varredura sequencial eficiente e quantização RaBitQ para baratear os cálculos de distância. Para não perder recall nas bordas das partições, o PRISM duplica vetores próximos aos limites entre grupos, e tudo isso roda sobre os mecanismos nativos de armazenamento, log e concorrência do próprio PostgreSQL.

Como instalar e usar

A extensão funciona em cima de colunas pgvector já existentes, então não exige migrar dados para um banco vetorial separado. Para habilitar o índice, bastam dois comandos:

CREATE EXTENSION pg_vectorsearch;
CREATE INDEX ON documents USING prism (embedding vec32_l2_ops);

O requisito mínimo é PostgreSQL 18, e o PRISM atualmente suporta vetores de até 1.968 dimensões, o que cobre a maioria dos modelos de embedding em uso hoje. Uma limitação relevante antes de considerar produção: buscas filtradas combinando WHERE e ORDER BY ainda não funcionam e só chegam na versão de disponibilidade geral.

Os números do benchmark

A Tiger Data publicou seus próprios testes com 100 milhões de vetores. O PRISM construiu o índice em 1 hora e 40 minutos, numa máquina com 128 GB de memória. O HNSW, no mesmo volume de dados, levou 42 horas rodando numa máquina com 512 GB. Os benchmarks não foram validados de forma independente, mas a Tiger Data usou uma ferramenta open source para medir recall@10 contra resultados de busca exata, comparando os dois índices na mesma configuração de PostgreSQL e no mesmo tipo de instância, com o HNSW usando o halfvec de 16 bits do pgvector.

A diferença de quase 25 vezes no tempo de build, com um quarto da memória, é o número que mais chama atenção, mas vale lembrar que vem de um teste controlado pela própria fabricante do produto.

O que ainda falta amadurecer

O ponto mais frágil hoje é manter o índice atualizado conforme os dados mudam. O rebalanceamento incremental não está totalmente implementado, o que significa que, em cargas com muita escrita, pode ser necessário reconstruir o índice para manter a eficiência da busca. Freedman explica o desafio:

O problema mais difícil é manter o clustering à medida que o dataset muda. Os centróides não se movem automaticamente quando novos vetores chegam, e as posting lists perdem gradualmente sua localidade física original. Hoje oferecemos suporte limitado à divisão sob demanda de posting lists grandes demais em índices flat, mas as operações de rebalanceamento mais gerais, incluindo merge e reatribuição, ainda não estão implementadas.

Michael Freedman, cofundador e CTO da Tiger DataThe harder problem is maintaining the clustering as the dataset changes. Centroids don't automatically move when new vectors arrive, and posting lists gradually lose their original physical locality. We currently support limited on-demand splitting of oversized posting lists for flat indexes, but the more general rebalancing operations, including merging and reassignment, are not implemented yet.

Soma-se a isso a ausência de busca filtrada (WHERE combinado com ORDER BY), recurso comum em aplicações reais que combinam metadados com similaridade semântica, como filtrar por categoria de produto antes de rankear por embedding.

Como a comunidade recebeu a notícia

Uma discussão popular no Hacker News mistura interesse técnico com cautela. Os comentários questionam a validação independente dos benchmarks, se o pg_vectorsearch vai substituir o pgvectorscale (outra extensão da própria Tiger Data) e a falta de suporte a buscas filtradas. Hermon Hagos resumiu o entusiasmo moderado:

Busca vetorial ficou mais barata [...] Para quem está construindo apps de RAG em um único banco e com orçamento apertado, isso importa. Busca semântica rápida sem subir um vector store separado ou um servidor maior é dinheiro de verdade economizado. Ainda é alpha, então não é para colocar em produção para clientes ainda, mas é algo para acompanhar de perto.

Hermon Hagos, comentário no Hacker NewsVector search just got cheaper (...) For those of us building RAG apps on one database and a tight budget, that matters. Fast semantic search without spinning up a separate vector store or a bigger server is real money saved. It is still alpha, so do not ship it to clients yet, but this is one to watch closely.

A Tiger Data já sinalizou o próximo passo na própria família de produtos: o pgvectorscale, extensão que a empresa mantinha até então como sua principal resposta de performance ao pgvector puro, vai passar para modo de manutenção, dando lugar ao pg_vectorsearch como aposta principal.

O que muda para quem desenvolve no Brasil

Para times brasileiros que hoje rodam RAG ou busca semântica em cima de pgvector, o pg_vectorsearch ainda não é opção para produção: é alpha, sem rebalanceamento completo e sem busca filtrada, recurso que praticamente toda aplicação real de RAG usa mais cedo ou mais tarde. Mas o código está aberto no GitHub do projeto e já dá para rodar em ambiente de teste com PostgreSQL 18, usando as colunas pgvector existentes sem precisar migrar schema.

O caminho razoável para quem quer avaliar: instalar a extensão num banco de desenvolvimento, criar o índice PRISM ao lado do HNSW já existente e comparar recall e tempo de consulta com o próprio dataset, antes de apostar em qualquer benchmark de terceiros. Se os números da Tiger Data se confirmarem fora do laboratório, a conta de infraestrutura para busca vetorial dentro do PostgreSQL, sem subir um vector store dedicado como Pinecone ou Qdrant, fica bem mais barata de sustentar.

Fonte: InfoQ