Two years ago, adding semantic search meant adding a vector database. That reflex is now expensive and often wrong.
The landscape shifted quietly. pgvector is no longer the slow option, and the question has become genuinely situational rather than obvious.
What Changed
With pgvectorscale added, PostgreSQL now delivers reported figures around 471 queries per second at 99% recall on 50 million vectors. That is not a compromise number, that is a production number for the vast majority of applications.
The practical guidance across 2026 comparisons converges: if you already run PostgreSQL and sit under roughly 50 to 100 million vectors, pgvector wins on cost, operational simplicity and reliability.
The Thresholds That Justify a Dedicated Database
| Signal | Threshold | Why it matters |
|---|---|---|
| Vector count | Beyond 50 to 100 million | Index build and memory pressure become the job |
| Latency requirement | Sub-20ms p99 | Dedicated engines are built for this |
| Write throughput | Continuous high-volume ingest | Index maintenance competes with your queries |
| Filtering complexity | Heavy metadata filtering at scale | Where implementations differ most |
| Team | You have someone to operate it | An unowned database is a future incident |
Hit two or more of those and a dedicated store earns its place. Hit none and you are buying operational complexity for a benchmark you will never observe.
The Hidden Cost Of Splitting Your Data
The argument for Postgres is rarely about raw speed. It is about the join.
When your vectors live beside your relational data, filtering by customer, permission or date is a WHERE clause. When they live in a separate service, that same filter becomes application logic, two round trips and a consistency problem. You now maintain two sources of truth and a synchronisation job, and that job will break on a Friday.
Spend the Money Somewhere Better
Here is the uncomfortable truth about most retrieval quality complaints: the database was never the problem.
Bad chunking, missing metadata and weak embeddings cause far more poor answers than query latency does. If your RAG system returns irrelevant passages, a faster index returns those same irrelevant passages faster. Fix the input pipeline first, and put the saved budget into better embeddings and a proper evaluation set.
A Decision Path You Can Follow Today
- Already on Postgres, under 10 million vectors? Use pgvector. Stop reading.
- Under 50 million with normal latency needs? pgvector with pgvectorscale. Revisit at scale.
- Above 100 million, or need sub-20ms p99? Evaluate dedicated stores properly, with your own data.
- Billions of vectors or constant heavy ingest? Dedicated, and budget for someone to own it.
- Unsure? Start on Postgres. Migrating out later is far easier than the reverse.
Conclusion
Default to Postgres and let scale force your hand. The thresholds that justify a dedicated vector database are specific and measurable: roughly 50 to 100 million vectors, sub-20ms p99 latency, or sustained heavy write throughput. Below those, you are choosing a synchronisation job over a WHERE clause. Spend the difference on chunking and embeddings, which is where retrieval quality actually lives.
Frequently Asked Questions
Is pgvector fast enough for real-time search?
For most applications, yes. With pgvectorscale it handles hundreds of queries per second at high recall on tens of millions of vectors. Sub-20ms p99 at very large scale is where it starts to strain.
What if we outgrow Postgres later?
Migrating vectors out is mostly a re-index operation and is well trodden. That asymmetry is exactly why starting on Postgres is the low-regret choice.
Do we need vectors at all?
Sometimes not. Keyword search with good metadata beats semantic search on precise, jargon-heavy corpora. Hybrid search usually beats both, and costs less than people expect.