The most expensive vector-database decision is the one made too early. A team stands up Pinecone in week one, wires a sync pipeline to keep it consistent with Postgres, and now operates two sources of truth for data that lived happily in one. Half the time, pgvector would have carried the whole thing.
We build production RAG for real customers, and the first question we ask is not "which vector database" — it's "do you need one that isn't the database you already have."
What pgvector actually removes
pgvector is a Postgres extension. Your embeddings become a column, next to the row they describe. That single fact cascades:
- One system, not two. No separate store to provision, back up, secure, monitor, and keep in sync. The vector lives with its source of truth.
- Filters are just SQL. "Nearest chunks from tenant X, doctype Y, newer than Z" is a
WHEREclause and a join, not a proprietary filter DSL. Your existing indexes and permissions apply. - Transactional consistency. The embedding is written in the same transaction as the row. There's no eventual-consistency window where your data and your vectors disagree — the failure mode that makes external vector stores subtly wrong after a bad deploy.
For a startup MVP or any small-to-medium corpus, that is often the entire answer. Adding Pinecone here adds a system to operate, not capability you can use.
Where pgvector stops being enough
pgvector is not magic, and pretending it scales forever is how teams get burned in the other direction. It strains in three predictable places:
- Index build time and memory. As vectors climb into the tens of millions, HNSW index builds get slow and memory-hungry, and they compete with your transactional workload for the same box.
- Write-heavy churn. Corpora that re-embed constantly force frequent index maintenance. Postgres would rather your vectors sat still.
- Query volume at scale. Very high vector-query throughput starts to contend with the reads and writes your app already needs from that database.
When those show up in your Postgres metrics — not in a blog post's benchmark — that's the cue to move. And "move" doesn't have to mean Pinecone; a self-hosted Qdrant keeps you in control while lifting the vector load off Postgres.
What Pinecone buys, and what it costs
Pinecone scales horizontally without you tuning an index or sizing a node, and it never competes with your primary database because it is separate. That separation is exactly the trade: you gain elastic scale and lose transactional consistency with your source data, plus you take on a sync pipeline and a bill that grows with storage and queries.
That is a good trade at scale and a bad one before it.
Which should you pick
If you already run Postgres and your corpus is small-to-medium, start with pgvector. One fewer system, filters that are plain SQL, and vectors that never drift from your data. Spend the saved complexity budget on chunking and reranking, which move answer quality far more than the store does.
Move to Pinecone — or a self-hosted Qdrant if you want to keep control — when index build times, memory pressure, or write churn start showing up in your Postgres metrics. Let the database tell you when it's done, instead of guessing on day one. If you're weighing the dedicated options, our Pinecone vs Weaviate vs Qdrant comparison walks that fork.