Pinecone 發佈開源 Postgres 向量搜尋擴充功能 pg_pinecone

Pinecone on October 27, 2026 released pg_pinecone, an open-source Postgres extension licensed under Apache 2.0 that brings the vector search engine the company says it runs at scale to the pgvector columns applications already store. In company-reported benchmarks, the extension’s native index for 1 million 768-dimension vectors measured 136 MB, against 2.0 GB for HNSW on halfvec and 4.1 GB on full-size vectors.

The release was presented in an announcement post written by Harshita Daddala and Anthony Mahanna. According to the post, the common way to run vector search in Postgres is a graph index such as HNSW, which requires increasing amounts of memory to maintain performance, takes a long time to build, and degrades accuracy on filtered search; when a query is scoped to one user or one tenant, a graph index can return fewer rows than the query’s LIMIT. pg_pinecone instead applies the filter during the search, which Pinecone said lets a narrow scope still return a full set of results, and on its default engine the data never leaves Postgres.

Three Engines Behind One Index

pg_pinecone works with vector columns already held in pgvector. An application connects to Postgres the same way and sends the same SQL, such as ORDER BY embedding <=> $1 LIMIT 10, while tables, including the full vectors, stay where they are and Postgres remains the system of record.

Each table uses one of three engines. The native engine, the default, builds and searches its index entirely inside Postgres with no Pinecone account, API key, or network calls. The pgvector engine searches an existing pgvector index, HNSW or IVFFlat, and the project’s GitHub repository describes it as suited to tables that already have a pgvector index and do not filter. The remote engine sends search to a serverless index in Pinecone’s managed service, intended for tables that have outgrown one Postgres server. Switching a table between engines takes one call to pinecone.set_engine(), queries do not change, and every switch can be reversed.

How the Native Engine Searches

Like pgvector’s HNSW, the native engine uses an approximate nearest neighbor algorithm, but it replaces the graph with an inverted file index that groups similar vectors into clusters. Each vector is stored as a quantized RaBitQ code, about one bit per dimension plus a few correction values, using a method the post credits to Gao and Long, SIGMOD 2024. The codes for each cluster are packed together, so a search reads a few contiguous pages instead of hopping across a graph.

A search runs in three steps: probe the nearest clusters by comparing the query vector with each cluster’s centroid, compute an estimated distance for each row from its RaBitQ code and keep the best candidates, then rerank those candidates using their full vectors from the table.

Filtering happens inside that search. Pinecone said pgvector’s HNSW post-filters, finding nearest neighbors first and applying the WHERE clause afterward, so a narrow filter discards most candidates and iterative scans refill the list at a cost in time and, when relaxed_order is used, accuracy. The native engine stores one filter-column value next to each row’s code and counts rows per value at build time. For narrow filters, by default 3% of rows or fewer, it pre-filters, scanning every matching row across all clusters and scoring each with its full vector so results are exact. For wider filters it uses single-stage filtering, searching up to half of the nearest clusters and checking the filter inside each cluster before scoring.

New inserts join the nearest cluster and are searchable immediately. Because centroids stay where the build placed them, the post advises running REINDEX or enabling automatic maintenance after large changes, such as a bulk load that doubles the table, to rebalance the clusters.

Benchmarks Reported by Pinecone

Pinecone compared the native engine with pgvector’s HNSW index, using full-size vectors and halfvec, on 1 million wiki_dpr vectors with 768 dimensions. Tests ran on an AWS r6id.4xlarge instance with 16 vCPUs and 128 GB of RAM, with unfiltered latency, build time, and index size measured in one session on PostgreSQL 17, filtered search in another on PostgreSQL 18, and a memory-capped configuration in a third. Latency is reported as median p50 at k=10 with one client, and the company said the full setup and the commands to rerun the tests are in a benchmark harness README in the repository.

For the 1 million vectors, Pinecone reported a 136 MB native index, compared with 2.0 GB for HNSW on halfvec and 4.1 GB on full-size vectors. On unfiltered search, the company reported 1.3 ms latency at 0.95 recall against 1.7 ms for HNSW on halfvec and 2.7 ms on full-size vectors, and 2.3 ms at 0.99 recall against 4.7 ms and 6.7 ms. With a filter matching 10% of rows, Pinecone reported the native engine reached 1.000 recall in 12.3 ms using single-stage filtering, while HNSW with iterative scans reached 0.920 recall at best in 5.9 ms; with a 1% filter, it reported 0.981 recall at 8.3 ms. Build times came in at a reported 45 seconds for the native engine versus 62 seconds for HNSW on halfvec and 79 seconds on full-size vectors.

Availability and Optional Pinecone Features

pg_pinecone requires PostgreSQL 17 or 18, superuser access, and pgvector installed on the server. It installs from prebuilt releases on GitHub or as the pineconeteam/pg_pinecone image on Docker Hub, which the README describes as the pgvector/pgvector image with pg_pinecone added, published with one tag per Postgres major version such as 0.11.0-pg17; running the remote engine also requires loading the extension through shared_preload_libraries. Setup creates the vector and pg_pinecone extensions and builds an index with a pinecone.create_index() call, and the project can be built from source with a Rust toolchain and cargo-pgrx 0.19.2.

With an optional Pinecone API key, the remote engine syncs embeddings to a Pinecone index in the background while searches keep running in Postgres until the copy finishes. The post describes three more optional features: embed() calls Pinecone’s inference service to turn text into embeddings from SQL, works with both the native and remote engines, and is covered for a first build by Pinecone’s free tier; BM25 full-text search runs alongside vector search on the same table, with BM25, vector, or hybrid queries issued from SQL; and rerank() reorders top results with Pinecone’s reranking models.

Documentation on docs.pinecone.io covers installation, the storage engines, engine switching, and full-text search, while the repository adds a SQL reference, an operator runbook, and a disaster-recovery guide. Pinecone described this as the project’s first release, said it maintains pg_pinecone and reviews every pull request, and said it will build the public roadmap from feedback shared through GitHub issues, its Discord community, and monthly office hours.