pgvector vs Pinecone: When the Cheap Option Is the Right One

TL;DR

• Below roughly 10 million vectors, pgvector with an HNSW index is fast enough that the vector layer will almost certainly never be your bottleneck.
• The performance difference between the two is smaller than the embedding API call that precedes the search, and far smaller than the LLM generation that follows it.
• Pinecone's hidden cost is architectural: you now own two data stores, synchronisation code, and two billing lines.
• The answer flips somewhere between 50 and 100 million vectors, and only if you cannot dedicate engineering time to tuning PostgreSQL at that scale.
• pgvector 0.8.x (latest stable: 0.8.5 as of July 2026) fixed the filtered-query recall problem that was its most legitimate weakness.

Most of the pgvector vs Pinecone debate is settled by a single question: how many vectors do you actually have today, and how many will you realistically have in twelve months? Everything else — latency benchmarks, recall numbers, feature tables — matters only after you answer that.

I have spent time on both sides of this decision building RAG systems for clients. The pattern I keep seeing is teams reaching for Pinecone on day one because it feels like the serious choice, then discovering the operational and financial weight of a second managed data store six months later. That is not a knock on Pinecone. It is a genuinely good product. But the case for it is narrower than the marketing suggests, and the case for pgvector is stronger than it was even a year ago.

What Has Actually Changed in pgvector?

The version history matters here. The latest stable release is pgvector 0.8.5, shipped on July 8, 2026. The 0.8 line is where most of the meaningful hardening happened.

pgvector 0.8.0 added iterative index scans — a technique to prevent "overfiltering," or not returning enough results to satisfy the conditions of a query. You can enable iterative scanning with the hnsw.iterative_scan and ivfflat.iterative_scan parameters; if an initial index scan does not satisfy the query conditions, pgvector continues to search the index until it hits a configurable threshold.

That matters because filtered vector search — find the top-10 similar documents where tenant_id = 42 AND created_at > 2026-01-01 — is the actual query shape in almost every production RAG system. The durable wins in the 0.8 line are iterative index scans that fix overfiltering, parallel HNSW index builds that cut build times on multi-core machines, and halfvec quantization that roughly halves storage.

One note worth flagging for anyone running parallel HNSW builds: pgvector 0.8.2, released February 26, 2026, fixes a buffer overflow with parallel HNSW index builds (CVE-2026-3172), which can leak sensitive data from other relations or crash the database server. If you are on 0.8.0 or 0.8.1, upgrade before enabling parallel builds.

Amazon Aurora PostgreSQL now supports pgvector 0.8.0, and AWS reports the release delivering up to 9x faster query processing and 100x more relevant search results for filtered queries, addressing key scaling challenges that enterprise AI applications face. I have not independently verified those figures at the application layer, so treat the headline numbers as directional rather than replicable on your specific workload.

Where Does the Performance Gap Actually Open?

For workloads under a million vectors, both return results in single-digit to low double-digit milliseconds. The performance difference between them is smaller than the latency of the embedding API call that precedes the search, and far smaller than the LLM generation that follows it in a RAG pipeline.

For datasets under 10 million vectors on modern hardware, pgvector with HNSW is fast enough that you will almost certainly never have a performance problem caused by the vector search layer. At 1 million vectors, you are looking at sub-4ms p95 latency and thousands of QPS. At 10 million vectors with good index parameters, a well-provisioned PostgreSQL instance handles the load comfortably.

Above 5 to 10 million vectors, pgvector requires careful tuning of shared_buffers, work_mem, and HNSW parameters to maintain fast queries. Pinecone handles this automatically. At hundreds of millions or billions of vectors, pgvector hits practical limits tied to your instance's memory, while Pinecone is designed for that scale.

There is a middle path worth knowing about. Timescale's pgvectorscale extension introduces StreamingDiskANN, a disk-based index that does not need everything in memory. Timescale's benchmarks on 50 million vectors show self-hosted Postgres cost at roughly $835 per month on EC2, compared to Pinecone's $3,241 per month (s1 tier) or $3,889 per month (p2 tier). I have not run pgvectorscale in production myself, so I am citing that result with the caveat that Timescale has an obvious interest in the outcome. Independent replication would be welcome.

The Operational Cost Nobody Prices In

This is the part of the decision that gets skipped in benchmark posts, because it does not produce a clean number.

With Pinecone, your documents live in Postgres and your embeddings live in Pinecone. You maintain two data stores for what is logically one entity. That means two backup strategies, two monitoring setups, synchronisation code to keep them consistent, and two lines on your infrastructure bill. If a document is deleted, you need to handle the cascade in both systems. If you need to reindex with a new embedding model, you do it twice.

With pgvector, your vectors live alongside user accounts, API keys, usage logs, and billing data — one connection pool, one backup strategy, one deployment. And the query ergonomics are different in kind, not just degree. SQL is a superpower for vector search. Need to find similar documents where the uploader is a verified account and the item was created in the last seven days? That is a single SQL query with pgvector. With a standalone vector database, that is a vector search, then a filter, then a join with your application database.

On the cost side: pgvector is effectively free — you pay only for the Postgres instance you already run, roughly $50–$180 per month on RDS. At 10 million vectors, Pinecone Serverless costs roughly $70 per month, while pgvector on RDS costs roughly $45 per month. At 100 million vectors, the gap explodes: Pinecone can reach $700 or more per month, while self-hosted pgvector stays under $100 per month.

The Pinecone billing model has one more wrinkle: capacity fees are a variable reservation charge that activates at sustained high concurrent load and are not surfaced in the base pricing — they are the primary source of unexpected bills at AI agent production scale. The gap between the pricing page estimate and the actual monthly bill averages 2.5x to 4x. That is not an argument against Pinecone; it is an argument for running the math on your real query volume before committing.

Where Does Pinecone Actually Win?

I want to be fair here, because there are genuine Pinecone-first scenarios.

Pinecone's hybrid search — combining dense embedding vectors with sparse BM25-style keyword signals — is production-ready and well-documented. In pgvector, you can approximate this with a combination of tsvector full-text search and vector similarity, but the query engineering is non-trivial and the ranking fusion logic falls on you.

Also worth noting: pgvector's metadata filtering happens as a post-filter on the candidate set, not inside the HNSW graph. On a 5 million vector collection with a 10% selectivity filter, you are scanning 500K candidates to return 50K. Qdrant handles this inside the graph traversal and is materially faster for selective queries. The iterative scan feature in 0.8.x mitigates the recall side of this problem, but the throughput cost of scanning a large candidate set remains.

If you are building a very large scale semantic search product, something in the hundreds of millions of items range, Pinecone is worth evaluating seriously. Its architecture is designed for that problem in a way that PostgreSQL is not. A single PostgreSQL instance at that scale requires serious engineering work.

Factor	pgvector	Pinecone
Up to ~10M vectors	Strong: sub-4ms p95, no extra infra	Competitive but pricier per month
10M–50M vectors	Requires HNSW tuning; pgvectorscale helps	Easier ops, higher cost
50M–100M+ vectors	Hits single-node memory limits; sharding needed	Purpose-built; maintains recall automatically
Relational joins	Native SQL — one query	Separate query + application-layer join
Filtered search recall	Fixed in 0.8.x with iterative_scan	Handled automatically
Hybrid search (dense + sparse)	Possible but requires manual ranking fusion	Production-ready out of the box
Monthly cost at 10M vectors	~$45 (RDS) or near-zero if instance already exists	~$70, plus capacity fees at high load
Data stores to operate	One (your existing Postgres)	Two (Postgres + Pinecone)
Operational expertise required	PostgreSQL (most teams have this)	Pinecone-specific (managed, but still a new system)

What I Reach For, and Why

On the RAG and LLM work I do — see RAG and LLM development — the starting point is always pgvector unless there is a specific reason to reach for something else. The reason is simple: the teams I work with already run PostgreSQL, so pgvector adds a CREATE EXTENSION vector; and an index. There is nothing new to operate, monitor, back up, or pay for separately.

The ai-seo-platform project is a good illustration. That build required semantic similarity across a content corpus, with metadata filters for date ranges and ownership — exactly the query shape where pgvector's SQL-native joins pay off. A two-system setup would have added synchronisation complexity for no performance benefit at that scale. You can read the details at /work/ai-seo-platform.

If you want more on the broader PostgreSQL performance picture — index design, query planning, connection pooling — the post on optimising PostgreSQL performance covers the foundations that make pgvector useful at scale. And if you are building the full RAG pipeline, the post on building a production-ready RAG system with LangChain and Pinecone walks through the Pinecone path in detail, which gives you a fair comparison against what pgvector requires.

FAQ

Can pgvector handle production workloads in 2026?

Yes. pgvector is absolutely production-grade in 2026. Companies including Supabase, Neon, and Instacart run it in production at significant scale. The 0.8.x series addressed the filtered-query recall issues that were its most legitimate weakness in earlier versions.

At what vector count does the answer flip toward Pinecone?

The practical ceiling for pgvector on a single-node PostgreSQL instance is roughly 50 million vectors on a well-provisioned instance — the limit is the instance, not pgvector itself. The gap opens up at very large scale: if you have 100 million or more vectors and need consistently low latency at high concurrency, Pinecone's dedicated infrastructure starts pulling ahead. That said, pgvectorscale with StreamingDiskANN extends the single-node ceiling materially for teams willing to add that dependency.

Does Pinecone's serverless model make it cheaper for small projects?

As of 2026, Pinecone has fully committed to serverless as the default; pod-based indexes are legacy. The pricing is simpler — read units, write units, storage — with no idle compute charge. However, the paid Standard tier carries a $50 per month minimum regardless of usage. For a small project already running Postgres, paying a mandatory $50 floor for a second data store is hard to justify when pgvector costs nothing incremental.

Is hybrid search (dense + sparse) a reason to choose Pinecone over pgvector?

It can be. Pinecone's hybrid search — combining dense embedding vectors with sparse BM25-style keyword signals — is production-ready and well-documented. In pgvector, you can approximate this with a combination of tsvector and vector similarity, but the query engineering is non-trivial and the ranking fusion logic falls on you. If hybrid search is a core feature of your application and your team does not want to own that fusion logic, Pinecone has a genuine advantage here.

What is the biggest hidden cost people miss with Pinecone?

Two things. First, the architectural cost: you are now responsible for keeping your relational data and your vector store consistent. Deletes, updates, and reindexing all need to happen in both systems. Second, capacity fees — a variable reservation charge that activates at sustained high concurrent load — are not surfaced in the base pricing and are the primary source of unexpected bills at AI agent production scale. Model the actual query volume before signing off on the budget.