Pinecone lança Pg_pinecone, uma extensão de busca para Postgres de código aberto

Pinecone lançou em 27 de outubro de 2026 o pg_pinecone, uma extensão de código aberto para Postgres, licenciada sob a Apache 2.0, que leva às colunas pgvector já armazenadas pelas aplicações o mecanismo de busca vetorial que, segundo a empresa, ela opera em grande escala. Em benchmarks divulgados pela empresa, o índice nativo da extensão para 1 milhão de vetores de 768 dimensões mediu 136 MB, contra 2,0 GB para HNSW em halfvec e 4,1 GB para vetores de tamanho integral.

O lançamento foi apresentado em uma publicação de anúncio escrita por Harshita Daddala e Anthony Mahanna. Segundo a publicação, a forma mais comum de executar buscas vetoriais no Postgres é usar um índice de grafo, como HNSW, que exige quantidades cada vez maiores de memória para manter o desempenho, leva muito tempo para ser criado e tem a precisão reduzida em buscas com filtros; quando uma consulta é restrita a um usuário ou locatário, um índice de grafo pode retornar menos linhas do que o valor de LIMIT especificado na consulta. Em vez disso, o pg_pinecone aplica o filtro durante a busca, o que, segundo a Pinecone, permite que uma busca com escopo restrito ainda retorne um conjunto completo de resultados; com o mecanismo padrão, os dados nunca saem do Postgres.

Três mecanismos, um único índice

O pg_pinecone funciona com colunas vetoriais já armazenadas no pgvector. A aplicação se conecta ao Postgres da mesma forma e envia o mesmo SQL, como ORDER BY embedding <=> $1 LIMIT 10, enquanto as tabelas, incluindo os vetores completos, permanecem onde estão e o Postgres continua sendo o sistema de registro.

Cada tabela usa um de três mecanismos. O mecanismo nativo, que é o padrão, cria e consulta seu índice inteiramente dentro do Postgres, sem exigir uma conta ou chave de API da Pinecone nem chamadas de rede. O mecanismo pgvector consulta um índice pgvector existente, HNSW ou IVFFlat, e o repositório do GitHub do projeto o descreve como adequado a tabelas que já têm um índice pgvector e não usam filtros. O mecanismo remoto envia as buscas para um índice sem servidor no serviço gerenciado da Pinecone, destinado a tabelas que já ultrapassaram a capacidade de um único servidor Postgres. Para alternar uma tabela entre os mecanismos, basta uma chamada a pinecone.set_engine(); as consultas não mudam, e é possível reverter todas as alternâncias.

Como funciona a busca do mecanismo nativo

Assim como o HNSW do pgvector, o mecanismo nativo usa um algoritmo aproximado de vizinhos mais próximos, mas substitui o grafo por um índice de arquivo invertido, que agrupa vetores semelhantes em clusters. Cada vetor é armazenado como um código RaBitQ quantizado, com cerca de um bit por dimensão, além de alguns valores de correção, usando um método que a publicação atribui a Gao e Long, SIGMOD 2024. Os códigos de cada cluster são agrupados, de modo que uma busca lê algumas páginas contíguas em vez de percorrer o grafo de um lado para outro.

Uma busca é executada em três etapas: primeiro, sondar os clusters mais próximos, comparando o vetor da consulta com o centroide de cada cluster; depois, calcular uma distância estimada para cada linha com base em seu código RaBitQ e manter os melhores candidatos; por fim, reclassificar esses candidatos usando os vetores completos da tabela.

A filtragem ocorre durante a busca. Segundo a Pinecone, o HNSW do pgvector aplica filtros posteriormente: primeiro encontra os vizinhos mais próximos e, em seguida, aplica a cláusula WHERE. Assim, um filtro restrito descarta a maioria dos candidatos, e as buscas iterativas preenchem novamente a lista, com um custo em tempo e, quando se usa relaxed_order, em precisão. O mecanismo nativo armazena o valor da coluna de filtro ao lado do código de cada linha e contabiliza as linhas por valor durante a criação do índice. Para filtros restritos — por padrão, de 3% das linhas ou menos —, ele filtra primeiro, percorrendo todas as linhas correspondentes em todos os clusters e calculando a pontuação de cada uma com seu vetor completo, para que os resultados sejam exatos. Para filtros mais amplos, usa filtragem em uma única etapa: busca em até metade dos clusters mais próximos e verifica o filtro dentro de cada cluster antes de calcular as pontuações.

As novas inserções são adicionadas ao cluster mais próximo e podem ser consultadas imediatamente. Como os centroides permanecem onde foram posicionados durante a criação do índice, a publicação recomenda executar REINDEX ou ativar a manutenção automática após grandes alterações — como uma carga em lote que dobre o tamanho da tabela — para reequilibrar os clusters.

Benchmarks divulgados pela Pinecone

A Pinecone comparou o mecanismo nativo com o índice HNSW do pgvector, usando vetores de tamanho integral e halfvec, em 1 milhão de vetores wiki_dpr de 768 dimensões. Os testes foram executados em uma instância AWS r6id.4xlarge com 16 vCPUs e 128 GB de RAM. A latência sem filtros, o tempo de criação e o tamanho do índice foram medidos em uma sessão no PostgreSQL 17; a busca com filtros, em outra sessão no PostgreSQL 18; e uma configuração com limite de memória, em uma terceira sessão. A latência é informada como mediana p50 em k=10, com um cliente, e a empresa disse que a configuração completa e os comandos para repetir os testes estão em um README do conjunto de ferramentas de benchmark no repositório.

Para os 1 milhão de vetores, a Pinecone informou que o índice nativo tinha 136 MB, em comparação com 2,0 GB para HNSW em halfvec e 4,1 GB para vetores de tamanho integral. Na busca sem filtros, a empresa informou latência de 1,3 ms com recall de 0,95, contra 1,7 ms para HNSW em halfvec e 2,7 ms para vetores de tamanho integral; com recall de 0,99, a latência foi de 2,3 ms, contra 4,7 ms e 6,7 ms. Com um filtro que correspondia a 10% das linhas, a Pinecone informou que o mecanismo nativo alcançou recall de 1,000 em 12,3 ms usando filtragem em uma única etapa, enquanto o HNSW com buscas iterativas chegou, no máximo, a recall de 0,920 em 5,9 ms. Com um filtro de 1%, informou recall de 0,981 em 8,3 ms. O tempo de criação informado foi de 45 segundos para o mecanismo nativo, contra 62 segundos para HNSW em halfvec e 79 segundos para vetores de tamanho integral.

Disponibilidade e recursos opcionais da Pinecone

pg_pinecone requer PostgreSQL 17 ou 18, acesso de superusuário e o pgvector instalado no servidor. A instalação pode ser feita a partir de versões pré-compiladas no GitHub ou usando a imagem pineconeteam/pg_pinecone no Docker Hub, que o README descreve como a imagem pgvector/pgvector com o pg_pinecone adicionado, publicada com uma tag para cada versão principal do Postgres, como 0.11.0-pg17; para executar o mecanismo remoto, também é necessário carregar a extensão por meio de shared_preload_libraries. A configuração cria as extensões vector e pg_pinecone e gera um índice com uma chamada a pinecone.create_index(); também é possível compilar o projeto a partir do código-fonte usando uma cadeia de ferramentas Rust e o cargo-pgrx 0.19.2.

Com uma chave de API opcional da Pinecone, o mecanismo remoto sincroniza embeddings com um índice da Pinecone em segundo plano, enquanto as buscas continuam sendo executadas no Postgres até que a cópia seja concluída. A publicação descreve mais três recursos opcionais: chamadas a embed() usam o serviço de inferência da Pinecone para transformar texto em embeddings a partir do SQL, funcionam tanto com o mecanismo nativo quanto com o remoto e, para uma primeira compilação, estão cobertas pelo plano gratuito da Pinecone; a busca textual completa BM25 funciona junto com a busca vetorial na mesma tabela, permitindo executar consultas BM25, vetoriais ou híbridas a partir do SQL; e rerank() reordena os principais resultados usando os modelos de reclassificação da Pinecone.

A documentação em docs.pinecone.io aborda a instalação, os mecanismos de armazenamento, a alternância entre mecanismos e a busca textual completa, enquanto o repositório inclui uma referência de SQL, um manual de operações e um guia de recuperação de desastres. A Pinecone descreveu esta como a primeira versão do projeto, afirmou que mantém o pg_pinecone e analisa cada solicitação de pull, e disse que elaborará o roteiro público com base nas opiniões compartilhadas por meio de problemas no GitHub, da comunidade no Discord e de sessões mensais de atendimento.