Pinecone releases pg_pinecone, an open-source Postgres extension for vector search

What pg_pinecone does and the problem it targets

Pinecone says that AI features such as support assistants, product recommendation engines and agents with memory depend on finding the most relevant records quickly and accurately, and that for many teams this data lives in Postgres. The company argues that the common approach today, a graph index such as HNSW in pgvector, becomes expensive to scale. According to Pinecone, graph indexes need increasing amounts of memory to keep performance up and take a long time to build.

Pinecone also points to a second weakness: filtered search. When a query is scoped to one user or one tenant, a graph index can return fewer results than requested, so an application may miss answers it should have found.

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

Three engines and a different index design

Each table uses one of three engines, and switching between them takes one call to pinecone.set_engine() without changing queries:

• native (the default): pg_pinecone's own engine, which builds and searches its index entirely inside Postgres, with no Pinecone account, API key or network calls.
• pgvector: searches pgvector's HNSW index.
• remote: sends search to an index in Pinecone's managed service.

Instead of a graph, the native engine groups similar vectors into clusters using an inverted file index (IVF). It stores a quantized copy of each vector as a RaBitQ code, about one bit per dimension plus a few correction values. A search probes the nearest clusters, estimates distances from the compact codes, keeps the best candidates and reranks them using the full vectors from the user's table.

For 1 million 768-dimension vectors, Pinecone says the native engine builds a 136 MB index, compared with 2.0 GB for HNSW on halfvec and 4.1 GB on full-size vectors.

Filtering during search and reported benchmarks

Pinecone explains that pgvector's HNSW applies the WHERE clause after finding nearest neighbors. With a narrow filter, such as one tenant out of a hundred, most candidates are discarded and a query can return fewer rows than its LIMIT. The native engine filters during the search and chooses a strategy based on selectivity. For a narrow filter (3% of rows or fewer by default), it pre-filters, scanning every matching row across all clusters and scoring each with its full vector, so results are exact. For a wider filter, it uses single-stage filtering, searching more of the nearest clusters, up to half, and checking the filter inside each cluster.

The company reports these results from its own tests on 1M vectors with 768 dimensions (wiki_dpr) on an AWS r6id.4xlarge with 16 vCPUs and 128 GB RAM:

• At 0.95 recall, a query takes 1.3 ms, versus 1.7 ms for HNSW on halfvec and 2.7 ms on full-size vectors.
• At 0.99 recall, it takes 2.3 ms versus 4.7 ms and 6.7 ms.
• With 10% of rows matching, the native engine reaches 1.000 recall in 12.3 ms, while HNSW with iterative scans reaches 0.920 recall at best, in 5.9 ms.

Pinecone also states that the index builds faster than pgvector HNSW on the same data. The full setup and commands to rerun the tests are in a benchmark harness README. These figures are the company's own.

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

Optional scale and features with a Pinecone API key

The native engine is meant to cover search for many applications. With a Pinecone API key, the same extension offers optional extras. For growth beyond one server, the remote engine moves search to Pinecone with SELECT pinecone.set_engine('docs', 'remote');. Embeddings sync to a Pinecone index in the background, and searches keep running in Postgres until the copy finishes. Queries do not change, Postgres stays the source of truth, and users can switch back to native the same way.

For tables that hold text but no embeddings, an embed() function calls Pinecone's inference service, so users do not need to host a model or manage another provider's key. Pinecone says its free tier covers a first build.

What it means for Postgres users

For teams that already keep vectors in Postgres, pg_pinecone offers an alternative index without a second system to run, according to Pinecone. The focus is on smaller memory use, quicker index builds and filtered queries that return full result sets, which matters for multi-tenant applications. Because the extension reuses existing pgvector columns and SQL, and lets users move between engines with one call, adoption can be gradual. The performance claims come from Pinecone's benchmarks on one dataset and hardware setup, so results on other workloads may differ.