Vector Database vs pgvector: Do You 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 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 advice teams hear before they index a single document. It’s true for some systems, but premature for most. Most teams already run Postgres. pgvector runs inside Postgres, and it handles a large share of production retrieval workloads. It runs without a second data store. It adds no on-call rotation and no extra bill.
What pgvector buys you
pgvector buys you one fewer system to operate. Most backends already run Postgres. Adding vector search there is an extension, not a new service. You don’t provision it, secure it, back it up, or staff an on-call rotation for it. That operational simplicity compounds. Your vectors live in the same transactional boundary as the rest of your data. You can join a similarity search against relational filters in one query, under one consistency model, instead of combining results from two separate systems.
It also buys you a shorter path to shipping something you can validate. Standing up retrieval on data you already hold in Postgres means adding an extension and an index. You skip the vendor evaluation, the new cluster, and the sync pipeline: work that’s wasted if the retrieval use case doesn’t pan out.
The honest limit: at very large scale, or under very tight latency budgets, purpose-built vector indexes can outperform pgvector. If vector search is your system’s dominant workload, not a feature alongside relational data, a dedicated store’s design may fit better from the start.
What a dedicated vector database buys you
A dedicated vector store buys you indexing and query performance built for high-dimensional similarity search at scale. It also buys features some products lack in Postgres, like certain hybrid search rankings or fully managed auto-scaling. For a system where vector search 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. You provision it, operate it, and pay for it separately. You staff a separate on-call surface for it. Critically, your vectors and your relational data now sit in different transactional boundaries, so you carry a consistency problem pgvector doesn’t have. None of that is a reason to avoid dedicated vector stores. It’s a reason to reach for one once 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. That decision rests on an assumption about future scale, not a measurement of current scale. It pays the operational cost of a second data store for a workload that would have run fine on pgvector for the system’s entire lifetime. The less common but costlier mistake runs the other way: staying on pgvector well past a measured latency or recall ceiling. Nobody re-benchmarks after the corpus grows, so users get worse retrieval than the product should give them.
Both mistakes treat this as a one-time architectural stance instead of a decision to revisit against real, measured numbers. That’s the same discipline that matters everywhere retrieval quality is at stake. Retrieval is usually where RAG systems 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. 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. Build the retrieval layer as its own abstraction from day one, so 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. Corpus size and query volume set the ceiling. Your latency target and index type (IVFFlat vs HNSW) move it. Measure your actual recall and latency at your actual scale. Don't pre-emptively migrate off a number you read somewhere. Many production RAGRetrieval-Augmented Generation (RAG) retrieves relevant passages at query time and feeds them into an LLM's context. systems run comfortably on pgvector well into the tens of millions of vectors.
Link to this answer: At what scale does pgvector stop being good enough?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 is not the same as faster end-to-end. If your system also joins vector results against relational data, a dedicated store adds a network hop. It also adds a consistency problem pgvector doesn't have.
Link to this answer: Is a dedicated vector database always faster?03 What's the real cost of running a separate vector database?
A second data store: one to provision and secure, on top of what you already run for Postgres. You back it up and staff an on-call rotation for it too. That operational cost is often the deciding factor, more than per-query pricing. It's the same hidden-cost pattern we describe in our writing on what an AI feature costs.
Link to this answer: What's the real cost of running a separate vector database?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.
Link to this answer: Can I migrate from pgvector to a dedicated store later without a rewrite?