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 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 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 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 has the full technical breakdown.