Postgres pgvector vs a dedicated vector database: when to switch

The default advice when you add retrieval is to stand up a vector database. For most teams that’s the wrong first move, and the right one is an extension to a database you already operate.

Here’s where the threshold actually sits, and what changes on each side of it.

The comparison, honestly

	Postgres with pgvector	Dedicated vector store
Systems to operate	The one you already run	One more
Transactions with your data	Yes	No, two stores to sync
Filtering by metadata	SQL, well understood	Varies, sometimes awkward
Backups and restore	Already solved	New procedure to write
Scale ceiling	Millions of vectors	Far higher
Index tuning	Limited knobs	Extensive

A second datastore is a second thing to back up, monitor, secure and be woken by. That cost is invisible in a benchmark and unavoidable in production.

Why Postgres is enough for longer than you think

pgvector adds vector similarity search to Postgres, which means embeddings sit beside the rows they describe with the same transactions, backups and access control.

That co-location removes a whole class of bug. When a document is edited or deleted, both the record and its vector change in one transaction, rather than in two systems that drift apart.

Stale vectors returning deleted content is not a hypothetical. It’s the most common failure in split architectures, and it’s the one that produces a support ticket rather than a slow query.

Filtering is the other quiet advantage. Restricting results to one customer’s documents is an ordinary WHERE clause, and in several dedicated stores it’s a documented sharp edge.

What a dedicated store actually buys

Scale and tuning, both of which are real once you’re past a few million vectors with latency requirements.

The underlying algorithm is usually the same. Malkov and Yashunin’s HNSW work described a graph-based approach that “strongly outperforms” earlier open-source methods, and both pgvector and the specialists implement it.

What differs is how much control you get over the trade between recall and speed, and how well the system shards across machines when one is no longer enough.

At genuinely large scale the problem changes shape again. Johnson and colleagues built FAISS for billion-scale search on GPUs, and if you’re there this comparison isn’t the one you need.

The decision that matters more than either

Neither option fixes retrieval quality, and quality is where most systems disappoint.

Vector search alone misses exact matches: product codes, error numbers, names, version strings. Hybrid retrieval, running keyword and vector search together, is what nearly every serious system does.

The embeddings themselves matter as much as where they live. Reimers and Gurevych’s Sentence-BERT made sentence-level similarity practical, and picking an embedding model suited to your domain moves quality more than any storage decision.

Reranking helps further. Khattab and Zaharia’s ColBERT showed late-interaction scoring recovering much of the accuracy of full cross-attention at far lower cost, and a cheap first pass followed by a precise rerank is the standard shape.

None of that infrastructure fixes bad chunking, and chunking decides more than the engine does. Our guide to what vector stores do covers why splitting on structure beats splitting on character count.

The sync problem, concretely

Because the split-store failure is the expensive one, it’s worth walking through how it actually happens.

A document gets updated in your application database. The re-embedding job that should refresh its vector runs on a schedule, or fails quietly, or was never wired to that table in the first place.

From then on, search returns the old version of the truth. Nothing errors, nothing alerts, and the person who finds it is a user quoting text you deleted last month.

Deletion is worse than editing, because the stakes are usually higher. A record removed for legal reasons that persists as a vector is a compliance problem wearing an infrastructure costume, and it’s why the erasure duties covered in our piece on GDPR and AI systems reach retrieval pipelines too.

Keeping vectors in the same database doesn’t make you immune, but it makes the fix a transaction rather than a distributed systems project.

The costs nobody mentions

Changing your embedding model invalidates every stored vector. There’s no migration path; you re-embed the corpus, and that’s a real cost worth knowing before you pick a model rather than after.

Retrieving more is also not retrieving better. Stanford’s Lost in the Middle found accuracy degrades sharply for information in the middle of a long context, so passing twenty chunks often performs worse than passing five.

And measure retrieval separately from generation. If you only score final answers you can’t tell whether the model reasoned badly or was handed the wrong documents, and those need different fixes.

A worked sizing example

Numbers make the threshold real. Say you have 50,000 documents, chunked into roughly 400,000 pieces, each embedded as 1,536 numbers.

That’s about 2.5GB of vectors. A modest Postgres instance holds that comfortably, an HNSW index over it answers queries in single-digit milliseconds, and the whole thing fits inside infrastructure you were already paying for.

You’d need to grow that corpus by an order of magnitude, while also holding a strict latency budget under real concurrency, before the dedicated store earns its operational cost.

What to do

Under about ten thousand documents, skip both and compare vectors in memory. It takes milliseconds, needs no infrastructure at all, and you can defer this whole decision until the corpus grows.

From there to a few million, use pgvector in the database you already run, especially if you’re operating the whole stack yourself, which our guide to the self-hosted stack covers.

Move to a dedicated store when you can name the specific limit you hit: a latency target you’re missing, a corpus that outgrew one machine, or an index tuning need you can articulate.

Buying it before you can name that limit costs you an extra system to run and buys you a benchmark number nobody in your organisation will ever look at.