pg_pinecone Brings Pinecone’s Search Engine Into Postgres

Pinecone released pg_pinecone on October 27, an open-source extension that runs its vector search engine inside PostgreSQL 17 and 18 without a Pinecone account or separate service. Pinecone reports that on one million vectors the native engine's IVF + RaBitQ index uses 136 MB versus 4.1 GB for pgvector's HNSW index, and that index build time falls from 79 seconds to 45 seconds, while metadata filters are applied during the search rather than after it. The extension supports native, pgvector and remote engines behind identical SQL, letting teams migrate non-destructively by creating a native index and dropping the pgvector one.

Pinecone shipped pg pinecone on October 27 — an open-source extension that drops its production vector search engine directly into PostgreSQL 17 and 18. No Pinecone account required. No separate service to run. No data leaving your database. If you already run Postgres, you now have a real alternative to pgvector without the operational tax of managing another system. Three Engines, One Index, Identical Queries The design is clean. Every table gets one pg pinecone index, and that index runs on one of three engines: - native the default — runs Pinecone’s search engine entirely inside your Postgres instance. No external calls. - pgvector — defers to pgvector’s existing HNSW index. Use this for tables that already work fine at your scale. - remote — routes search to a Pinecone managed cloud index. Your escape hatch when you outgrow a single server. All three engines use identical SQL. You switch the engine without touching application code. That is not a minor point — it is the entire value of the architecture. What the Native Engine Actually Fixes pgvector has two documented production problems that teams have been working around for years. The memory wall. pgvector’s HNSW index stores the full graph in memory. On one million vectors, that index weighs 4.1 GB . pg pinecone native uses IVF + RaBitQ — it stores a compact summary of each vector instead of the full graph. The same one million vectors: 136 MB . Index build time drops from 79 seconds to 45 seconds. At higher vector counts, this gap compounds fast. The filtering trap. pgvector applies metadata filters after the vector search completes. When a filter is selective — say, WHERE tenant id = $1 in a multi-tenant app — pgvector often can’t find enough results because it searched a broader set and then discarded most of it. pg pinecone native applies filters during the search, scanning clusters with the filter already active. Narrow scopes still return full result sets. These are not edge cases. If you are building multi-tenant RAG or any system where users have scoped data, pgvector’s post-filter behavior is a real accuracy problem that doesn’t show up in toy benchmarks. Installing pg pinecone pg pinecone requires PostgreSQL 17 or 18 and pgvector. Install via prebuilt binaries on GitHub https://github.com/pinecone-io/pg pinecone or the pineconeteam/pg pinecone Docker image. Then: CREATE EXTENSION vector; CREATE EXTENSION pg pinecone; -- Index a column with the native engine no API key needed SELECT pinecone.create index 'documents', 'embedding', 'native' ; -- Query -- same syntax as pgvector SELECT id, content FROM documents ORDER BY embedding <- ' 0.1, 0.2, ... '::vector LIMIT 10; That is the full setup for local vector search. No API key, no config file, no account registration required. Check the official quickstart https://docs.pinecone.io/guides/pg-pinecone/quickstart for Docker Compose examples and full configuration options. Native vs pgvector: The Numbers | | pgvector | pg pinecone native | pg pinecone remote | |---|---|---|---| | Runs inside Postgres | Yes | Yes | Query only | | Account required | No | No | Yes Pinecone | | Index size 1M vectors | 4.1 GB | 136 MB | Cloud-hosted | | Filter behavior | Post-search | During search | During search | Who Should Switch If you are running pgvector without hitting its limits, there is no urgent reason to migrate. pgvector works at modest scale with broad WHERE clauses. Switch to pg pinecone native if: - Your HNSW index is consuming more RAM than expected - You are running multi-tenant workloads and seeing recall drop on per-tenant queries - You are building new RAG or agent memory on Postgres and want to avoid pgvector’s known ceiling from day one Migration is non-destructive: create the native index, drop the pgvector index, done. Queries don’t change. Reversible if something breaks. Pinecone published a step-by-step migration guide https://docs.pinecone.io/guides/pg-pinecone/switch-from-pgvector covering the full transition. The Bottom Line pgvector made vector search accessible by piggy-backing on a database teams already ran. The tradeoff was a search engine not designed for the job. pg pinecone flips that — Pinecone’s actual production search engine, running inside the database you already operate, under an Apache 2.0 license, with no account required to get started. For Postgres shops building AI features today, this is the better starting point. The official announcement https://www.pinecone.io/blog/introducing-pg-pinecone/ has the full technical breakdown.