Vector Database vs pgvector: Do You Actually Need a Dedicated Store
Start on pgvector. Migrate to a dedicated vector database only when you hit a measured scale, latency, or feature ceiling it can't clear, not preemptively.
- You've measured pgvector hitting a real latency or recall ceiling at your actual scale
- You need vector-native features pgvector lacks (like advanced hybrid ranking or serverless auto-scaling) and you've confirmed you actually need them
- Your corpus is large enough (tens of millions of vectors and up) that specialized indexing meaningfully outperforms pgvector's
- Vector search is the primary workload, not a feature bolted onto an existing relational system
- You already run Postgres and don't want to operate a second data store
- Your corpus is small-to-mid sized and hasn't hit a measured performance ceiling
- You need transactional consistency between your relational data and your vectors
- You're still validating the retrieval use case and want to avoid premature infrastructure
“You’ll need a real vector database eventually” is the advice teams get before they’ve indexed a single document. It’s true for some systems and premature for most of them. pgvector, running inside Postgres you likely already operate, handles a large share of production retrieval workloads without a second data store, a second on-call rotation, or a second bill.
What pgvector actually buys you
pgvector buys you one fewer system to operate. If you already run Postgres — and most backends do — adding vector search is an extension, not a new service to provision, secure, back up, and keep someone on call for. That operational simplicity compounds: your vectors live in the same transactional boundary as the rest of your data, so you can join a similarity search against relational filters in one query, with one consistency model, instead of stitching together results from two systems that can drift out of sync.
It also buys you a shorter path to shipping something you can actually validate. Standing up retrieval on data you already have in Postgres is a matter of adding an extension and an index, not evaluating vendors, provisioning a new cluster, and building a sync pipeline to keep it current: infrastructure that’s wasted effort if the retrieval use case doesn’t pan out.
The honest limit: at very large scale or very tight latency budgets, purpose-built vector indexes can outperform pgvector’s, and if vector search is your system’s dominant workload rather than a feature alongside relational data, a dedicated store’s design center may fit better from the start.
What a dedicated vector database actually buys you
A dedicated vector store buys you indexing and query performance built specifically for high-dimensional similarity search at scale, along with features some products lack in Postgres, like certain hybrid search rankings or fully managed auto-scaling. For a system where vector search genuinely is the primary workload, at a scale where that specialization pays off, this is the right tool.
What it costs is a second system in your stack: a separate service to provision and operate, a separate bill, a separate on-call surface, and, critically, a consistency problem between your vectors and your relational data that pgvector doesn’t have, since the two now live in different transactional boundaries. None of that is a reason to avoid dedicated vector stores; it’s a reason to reach for one because you’ve measured a real ceiling, not because a blog post said you’d need it eventually.
The comparison
| Postgres + pgvector | Dedicated vector database | |
|---|---|---|
| Operational footprint | None new: extends existing Postgres | A second system: provisioning, backups, on-call |
| Transactional consistency with relational data | Native | Requires a sync layer between the two stores |
| Time to first working retrieval | Fast: extension + index on existing data | Slower: vendor eval, cluster setup, data sync |
| Performance at very large scale / tight latency | Good, with real limits | Purpose-built, generally stronger |
| Best fit | Vector search alongside relational data | Vector search as the dominant, standalone workload |
| Migration path | Straightforward if retrieval is abstracted | N/A |
Where teams get this wrong
The most common mistake is provisioning a dedicated vector database before indexing a single real document, based on an assumption about future scale rather than a measurement of current scale: paying the operational cost of a second data store for a workload that would have run comfortably on pgvector for the system’s entire lifetime. The less common but costlier mistake is the reverse: staying on pgvector well past a measured latency or recall ceiling, because nobody re-benchmarked after the corpus grew, and users are quietly getting worse retrieval than the product should provide.
Both come from treating this as a one-time architectural stance instead of a decision to revisit against actual, measured numbers. That’s the same discipline that matters everywhere retrieval quality is at stake, since retrieval is usually where RAG systems actually fail, not in the generation step downstream of it.
Our default
Start on pgvector if you’re already running Postgres. It gets you shipping and validating the retrieval use case without a second system to operate, and for a large share of production workloads, it never hits a ceiling that forces a change. Migrate to a dedicated vector database only once you’ve measured a real latency, recall, or scale limit pgvector can’t clear, and build the retrieval layer as its own abstraction from day one, so that migration, if it comes, is a swap, not a rewrite. We help teams size this decision against real corpus and query numbers as part of AI integration scoping. Get in touch before you provision infrastructure you might not need.
FAQ
Answers to the questions this decision raises.
01 At what scale does pgvector stop being good enough?
There's no universal number: it depends on corpus size, query volume, latency requirements, and index type (IVFFlat vs HNSW). The right approach is to measure your actual recall and latency at your actual scale rather than pre-emptively migrating off a number you read somewhere. Many production RAG systems run comfortably on pgvector well into the tens of millions of vectors.
02 Is a dedicated vector database always faster?
For pure vector search at very large scale, usually yes: that's what it's built for. But 'faster at vector search' isn't the same as 'faster end-to-end,' and if your system also needs to join vector results against relational data, a dedicated store adds a network hop and a consistency problem pgvector doesn't have.
03 What's the real cost of running a separate vector database?
A second data store to provision, back up, secure, and keep an on-call rotation for, on top of whatever operational discipline you already apply to Postgres. That operational cost is often the deciding factor, more than the per-query pricing, the same hidden-cost pattern we describe in our writing on what AI actually costs.
04 Can I migrate from pgvector to a dedicated store later without a rewrite?
Yes, if the retrieval layer is built as its own abstraction rather than queries hard-coded against Postgres-specific syntax throughout the app. That's an architecture decision worth making up front regardless of which store you start on.