pg_pinecone: open-source Postgres vector search, no API key

Pinecone, the company that sells a hosted vector database, just shipped pg_pinecone: an open-source Postgres extension that does vector search inside your own database. The default engine never calls Pinecone. No account, no API key, no second system. For a small business that runs AI search or a support bot on Postgres, that is a vendor telling you that you may not need its main product.

What actually happened

Pinecone announced pg_pinecone on October 27 under the Apache 2.0 license. The docs list three engines that index your existing pgvector columns:

• native (the default since v0.11.0): Pinecone's IVF plus RaBitQ index, built and searched fully inside Postgres. No network calls.
• pgvector: the standard pgvector HNSW or IVFFlat index.
• remote: syncs the table to a Pinecone serverless index in the background. Postgres stays the source of truth. This one needs an API key.

SQL helpers for embeddings, reranking and full-text search call Pinecone's services and need a key.

The catch: self-managed only. It needs PostgreSQL 17 or 18, pgvector and superuser access to install. That rules out most managed Postgres plans. Prebuilt archives need glibc 2.39 or later (Ubuntu 24.04, Debian 13) on Linux. There is also a Docker image, pineconeteam/pg_pinecone. The repo is at v0.11.0, released October 26. That is a 0.x version, and the blog calls it the first release.

The benchmark is Pinecone's. On 1 million 768-dimension vectors on one AWS r6id.4xlarge, Pinecone reports the native index at 136 MB against 2.0 GB for pgvector HNSW on halfvec. It reports 2.3 ms median latency at 0.99 recall against 4.7 ms. With a 1% filter, it reports 0.981 recall for native against about 0.92 for HNSW. One dataset, one machine, vendor-run. The harness is in the repo, so you can run it yourself.

Why it matters for your business

One database beats two. Most small-business AI search does not need a separate vector service. It needs product, ticket or document embeddings next to the rows they describe, filtered by store, customer or date in the same query. Keeping it in Postgres means one backup, one permission model and no sync job to break.

Filtered search is where pgvector hurts. If your bot searches "this customer's orders" or "in-stock items only," narrow filters with HNSW can return short or wrong result lists. That is the problem Pinecone says the native engine fixes. Test it on your own filters.

Check your host before you plan. On RDS, Supabase or Neon you probably cannot install it today. On your own VM or container, you can try it this afternoon.

Sources: Pinecone blog: Introducing pg_pinecone, Pinecone docs: pg_pinecone overview, pg_pinecone on GitHub.