This question comes up on nearly every project that adds retrieval to an existing application, and it usually gets answered on day one from a benchmark chart. That is the wrong input, and the decision is usually reversible in one direction and painful in the other.
Short version: start with pgvector if you are already on Postgres. Move when you have a measurement, not a benchmark.
Here is the reasoning, including the part that is genuinely in favour of dedicated stores.
What the benchmarks measure and why it misleads
Vector database benchmarks typically report queries per second and recall at a given k over a fixed corpus, unfiltered.
Production retrieval is essentially never unfiltered. You are searching the documents this tenant can see, from a date range, of certain types, excluding archived items. That is filtered approximate nearest neighbour search, and it is a substantially harder problem than the benchmark case.
Engines vary enormously here. Some apply filters during graph traversal and degrade gracefully. Some post-filter, which means requesting k=10 with a selective filter can silently return three results — the worst kind of bug, because nothing errors and quality just quietly drops.
Test your engine with your filter selectivity. A chart showing 10,000 QPS unfiltered tells you very little about 50 QPS with a tenant predicate attached.
The real argument for the extension: consistency
The advantage of pgvector is not speed. A dedicated engine will beat it on raw similarity search. The advantage is that your vectors live inside the same transaction as your data.
BEGIN;
DELETE FROM documents WHERE id = $1;
-- embeddings are in the same table or a FK-linked one
-- they are gone, atomically
COMMIT;
With a separate store, that becomes a distributed write. And distributed writes fail partially. The characteristic bug is deleted or newly-restricted content continuing to appear in retrieval results, which is an unpleasant conversation with a customer and a genuinely unpleasant one if the content was restricted for access-control reasons.
Permission filtering is the same story. In Postgres:
SELECT d.id, d.chunk
FROM documents d
JOIN acl a ON a.doc_id = d.id
WHERE a.tenant_id = $1
AND d.created_at > $2
ORDER BY d.embedding <=> $3
LIMIT 10;
The ACL is a real table with real foreign keys. In a dedicated store, tenant and permission data is denormalised into vector metadata and kept in sync by a process you now own. When someone's access is revoked, there is a window — and the length of that window is a security property of your system.
When a dedicated store is genuinely right
I do not want to strawman the alternative. There are real reasons to run one.
- Scale. Tens of millions of vectors and up, where purpose-built index structures and memory management materially outperform the extension.
- Strict latency under heavy filtering. If you need single-digit millisecond p99 with selective filters, dedicated engines have done more work on that specific problem.
- Advanced retrieval features. Multi-vector representations, native re-ranking, sparse-dense hybrid built in rather than assembled.
- Operational separation. Retrieval load genuinely isolated from your transactional primary — a legitimate concern once retrieval volume is significant.
If any of those describe you with evidence, take on the second system knowingly.
What deferring actually costs
The reason this decision is deferrable: migration from pgvector to a dedicated store is comparatively straightforward.
Your embeddings already exist. Your chunking pipeline already exists. What changes is the write path and the query path — real work, but bounded and well-understood, typically days rather than a rewrite.
Contrast the other direction. Starting with a dedicated store means building the synchronisation subsystem, the reconciliation job for drift, the monitoring for sync lag, and the handling for partial failure — on day one, before you know whether you needed any of it.
Plan the reindex now regardless
Whichever you choose, one thing is not optional.
You will change embedding models. A better one ships, pricing changes, or quality demands it. Vectors from different models are not comparable, so the entire index becomes invalid.
Build for this from the start:
-
Version your collections.
docs_v1_ada,docs_v2_embed3. Never one mutable index. - Store the model identifier with every vector, so you can tell what produced it.
- Reindex into the new collection while the old one serves traffic.
- Switch at the query layer behind a flag, and keep the old collection around long enough to roll back.
Teams that skip this do the migration during an unplanned outage window with traffic paused. It is entirely avoidable.
The thing that actually improves retrieval
One last point, because it is usually where the wins are.
Most retrieval quality problems are not vector problems. Hybrid retrieval — combining semantic similarity with keyword matching and metadata filters — consistently outperforms pure vector search on real corpora, particularly for queries with product codes, error strings, identifiers, or precise domain terminology, which is exactly where embeddings are weakest.
Postgres gives you full-text search and vector search in one query. That is a genuinely underrated property and it removes a reconciliation problem you would otherwise have between two ranking systems.
Frequently Asked Questions
Is pgvector production-ready?
Yes, for a large share of applications. With HNSW indexing it handles low millions of embeddings at acceptable latency, and it keeps vectors within the same transaction and permission model as your data.
Why do vector benchmarks mislead?
They typically measure unfiltered search, while production retrieval is always filtered by tenant, date, or type. Engines differ significantly in how they handle pre-filtered approximate search — some post-filter and silently return fewer results than requested.
When should we move to a dedicated vector store?
On measured evidence: tens of millions of vectors, strict p99 latency under selective filtering, a need for multi-vector or native re-ranking features, or genuine operational isolation of retrieval load.
How hard is migrating from pgvector later?
Comparatively easy — embeddings and chunking already exist, and only the write and query paths change. Starting with a dedicated store is the expensive direction, because you build a synchronisation subsystem before knowing whether you needed it.
What happens when we change embedding models?
The entire index becomes invalid, since vectors from different models are not comparable. Use versioned collections, store the model identifier alongside each vector, build the new index while the old serves traffic, and switch behind a flag.
Is pure vector search enough for quality retrieval?
Usually not. Hybrid retrieval combining semantic similarity with keyword matching and metadata filters performs better on real corpora, especially for queries containing identifiers or precise terminology.
Full guide — six database categories, OLTP versus OLAP, managed versus self-hosted, decision framework and cost structure: Best Database Software in 2026: A CTO Selection Guide.
More on how we approach LLM integration and AI development.
Top comments (0)