pgvector vs Pinecone in 2026: when each wins

Anserra runs on Postgres with pgvector. We chose that after a full evaluation against the managed vector databases, and the choice has held up as we’ve scaled. This is the honest version of the comparison.

I’ll skip the marketing pages and go to the details that matter in production.

The one-line version

Pinecone — fully managed, extreme throughput, opinionated data model. Good if you have one workload and need it to scale immediately.

pgvector — a Postgres extension. Same-database joins between vectors and structured data. Good if your app already uses Postgres, if you care about ownership, and if you can operate a Postgres cluster.

Pricing

At Anserra’s scale (~50 million chunks, ~15k QPS peak), Pinecone quotes tens of thousands per month. pgvector on a self-hosted Postgres 18 with 32 vCPU / 128 GB RAM costs under $1000/month all-in.

At small scale (< 1M vectors), the difference is negligible. At medium scale (10M+), the math starts to hurt.

Latency

Pinecone is faster on pure ANN throughput — that’s what it’s designed for. Sub-10ms p99 across regions is realistic.

pgvector’s HNSW index does 20–40ms p99 for typical 3072-dim workloads when `ef_search` is tuned. That’s slower, but for a chatbot answering in ~2s of end-to-end streaming latency, retrieval is not the bottleneck. The LLM is.

If you’re building semantic search where latency is the product, Pinecone wins. If you’re building RAG where retrieval feeds an LLM, pgvector is fast enough.

Filtering

This is where pgvector wins decisively.

Every retrieval query in a multi-tenant system needs a filter: “chunks belonging to chatbot X, uploaded after date Y, in language Z.” Pinecone supports metadata filters, but they’re a scan applied to ANN candidates. Complex filters slow queries significantly.

pgvector is Postgres. You can `WHERE` on structured columns using standard indexes before or after ANN. Compound predicates over structured and vector data are one query, not a two-round dance between databases.

Hybrid search

Pinecone added sparse-dense hybrid in 2024. It works but requires uploading a separate sparse vector alongside every dense one. That doubles ingestion cost.

pgvector combined with Postgres full-text search (`to_tsvector`) and a trigram index gives you three retrievers in one database. Fuse the ranks with RRF at query time. We wrote this up in detail.

Operations

Where Pinecone wins:

• You never operate the database.
• Backups, monitoring, replication, region failover — all done for you.
• If your engineering team is < 5 people, this is worth paying for.

Where pgvector wins:

• Standard Postgres operations knowledge transfers. If you can run a Postgres cluster, you can run this.
• Migrations are Prisma or plain SQL. No proprietary schemas.
• Data lives on servers you control. For customers in regulated verticals, this alone is often decisive.

What breaks under load

Pinecone — the most common failure I’ve seen is metadata index bloat. If you `upsert` millions of vectors with high-cardinality metadata (visitor IDs, timestamps), performance degrades and the fix is a full re-index.

pgvector — the most common failure is HNSW parameters chosen at low scale that don’t hold up. Rebuilding an index with `m=16, ef_construction=64` on a 50-million-row table takes several hours. Get the parameters right the first time by loading a realistic sample.

Both have vacuum-analog concerns. Pinecone hides them; pgvector requires you to run `VACUUM ANALYZE` on schedule.

Halfvec

pgvector’s HNSW index tops out at 2000 dimensions for `vector`. If you use OpenAI’s `text-embedding-3-large` (3072), you must index the `halfvec` cast instead. The cast is quantised to 16-bit floats — half the memory, negligible recall loss in our testing.

Getting this wrong causes silent full-table scans that only surface as latency degradation weeks later. If you take one thing away: check that your index is on `embedding::halfvec(N)` when N > 2000, and that your query casts identically.

When to pick each

Pick Pinecone when:

• Your workload is embedding-first — semantic search is the product.
• Your team can’t or won’t operate infrastructure.
• Latency below 10ms matters to your UX.

Pick pgvector when:

• You already have Postgres.
• You need filters over structured data alongside vectors.
• You want hybrid retrieval without stitching two databases together.
• Data residency or ownership is a hard requirement.

Our choice

Anserra runs on pgvector. Every customer we onboard runs against the same Postgres deployment we operate. The choice has held up as we’ve grown, and it lets us offer honest single-tenant deployments for enterprise customers who want their data on their own servers — something we couldn’t do on Pinecone without a rebuild.

If you want to see what a well-configured pgvector chatbot feels like: try Anserra free.