A team ships RAG on pgvector, it works, and then it keeps working right up until the nightly re-embed job starts colliding with the morning traffic peak. Now their primary Postgres — the one holding orders, users, sessions — is spending its afternoon rebuilding an HNSW index instead of serving the app. The instinct is to reach for a hosted vector cloud and be done. But most teams in this spot don't need to leave self-hosting; they need to stop asking one database to be two things.
We build production RAG for real customers, and we don't treat "move off pgvector" as a graduation everyone eventually attends. Plenty of systems never should. The useful question is narrower: what specific pressure is your Postgres box under, and is Qdrant the right thing to absorb it?
What pgvector is doing right, and why you keep it
pgvector puts the embedding in a column beside the row it came from. That colocation is the whole point. The vector and its source data commit in one transaction, so there is no window where a chunk exists but its embedding doesn't, or a document is deleted while its vector lingers. Your metadata filters are real SQL against your real schema — tenant scoping, permission checks, freshness windows — reusing indexes and access rules you already trust.
For a large share of production systems that is the finished answer, not a phase. If your corpus fits in memory and your write pattern is calm, adding a second store buys you complexity and a consistency problem you didn't have. Keep pgvector until it visibly stops paying for itself.
The pressure that actually pushes vectors out
pgvector doesn't fail on a recall cliff. It gets expensive in ways that show up on your own dashboards:
- Index maintenance steals from the app. As vectors grow into the many millions, HNSW builds and rebuilds get slow and memory-hungry, and they run on the same box answering your transactional queries. The vector workload starts winning fights it shouldn't.
- Filtered search at scale gets awkward. A highly selective
WHEREcombined with an approximate index can force the planner into choices that hurt either recall or latency. This is where "just add a filter" stops being free. - Write churn punishes you. Corpora that re-embed constantly keep the index in a state of near-permanent maintenance. Postgres would rather your vectors held still.
When those patterns are visible in your Postgres metrics — not in a vendor benchmark — that's the graduation signal. Notice it's an operational signal, the same kind that shows up in our pgvector vs Pinecone breakdown: the database tells you when it's done carrying vectors.
What Qdrant buys, and what it asks back
Qdrant is a dedicated vector engine you still run yourself. That framing matters, because the reflex move — off to a managed cloud — trades one problem for a different set. Qdrant lets you lift the vector load off Postgres while keeping your data on infrastructure you control.
Concretely, it gives you a purpose-built HNSW implementation tuned for vector workloads, payload filtering integrated into the index rather than layered on top, and sharding when a single node isn't enough. Its filtering design is the part that most often justifies the move for RAG teams: selective constraints stay first-class instead of fighting the index.
The cost is real and worth stating plainly. You now operate a second stateful system, and you own the sync path — every insert, update, and delete in Postgres has to reach Qdrant, and you lose the single-transaction guarantee that made pgvector safe. That reintroduces the eventual-consistency window you didn't have. It's a fair trade once Postgres is straining, and a bad one before.
Which should you pick
If pgvector is quietly serving your corpus and your writes are calm, stay put. Spend the complexity budget on chunking and reranking, which move answer quality far more than the store does. There's no prize for running a dedicated vector database you don't need.
Move to Qdrant when index maintenance, memory contention, or filtered-search quality start showing up as damage to your primary workload — and when you want to stay self-hosted rather than hand your corpus to a managed provider. If you're also weighing the managed options against Qdrant, our Pinecone vs Weaviate vs Qdrant comparison walks the three-way fork. And if the deeper question is whether embeddings are even the right approach for your problem, step back to RAG vs fine-tuning before you invest in any store at all. Let the database tell you it's time; don't guess on day one.