pgvector or a dedicated vector database?
For most applications the answer is the database you already run, and the threshold where that stops being true is higher than the marketing suggests.
Every RAG tutorial reaches for a dedicated vector database. Most applications building
one already run Postgres, and pgvector turns it into a vector store with an extension.
The interesting question is where that stops being enough.
What you get by staying put
One system to operate, back up and monitor. One connection pool. One place your data lives.
More importantly: transactional consistency and real joins. Your embeddings sit beside the records they describe, so you can filter by tenant, date, permission or status in the same query that does the similarity search — with the filter applied by the same engine that owns the data.
That last point is the one people underestimate. Pre-filtering by metadata is extremely common in production retrieval, and doing it across two systems means either over-fetching from the vector store and filtering afterwards, or maintaining a copy of your metadata in it.
Index choice is the real decision
Exact search compares against every vector. It is perfect and linear, which is fine into the tens of thousands and not beyond.
Approximate indexes trade a little recall for a lot of speed. IVFFlat partitions the space into lists and searches the nearest few — fast to build, and it needs enough data present at build time to partition sensibly. HNSW builds a navigable graph, gives better recall at the same speed, and costs more to build and more memory to hold.
The parameters are a dial between recall and latency, and the only way to set them is to measure recall on your own data against exact search.
An approximate index that nobody measured is a silent recall problem. Compare against exact search on a sample before trusting it.
When a dedicated store earns its place
At tens of millions of vectors, purpose-built systems pull ahead on both latency and memory efficiency.
When you need vector-native features Postgres does not have: sophisticated hybrid scoring, multi-vector documents, native sparse-dense fusion, per-namespace isolation at scale.
When the workload is genuinely separate — an embedding pipeline with its own scaling profile that you do not want sharing capacity with your transactional database.
Choosing without regretting it
Start with the database you have. The migration path to a dedicated store later is mechanical, and you will make the choice knowing your actual query patterns and volumes.
Start with a dedicated store and you have taken on an extra system, extra failure mode and a metadata synchronisation problem, in exchange for scale you may never reach.
Keep embeddings regenerable from source, whichever you pick. Model changes force re-embedding eventually, and the teams that suffer are the ones who treated the vector store as the system of record.