--- title: "pgvector vs Qdrant: when Postgres graduates to a dedicated vector store" excerpt: "You already run Postgres and pgvector is holding. The real question is not whether Qdrant is faster — it's which pressure finally pushes vectors out of your database, and why Qdrant is the store to catch them." date: "2026-07-15" lastModified: "2026-07-15" author: "Teo Deleanu" authorAvatar: "/team/teo.jpg" tags: ["Production AI", "AI Engineering", "RAG", "Vector Databases"] keywords: - "pgvector vs Qdrant" - "when to move from pgvector to a vector database" - "qdrant vs postgres vector search" - "self-hosted vector database" - "pgvector scaling limits" options: ["pgvector", "Qdrant"] verdict: "Stay on pgvector while vectors live comfortably next to your rows and filters stay transactional. Graduate to Qdrant when index rebuilds, memory pressure, or filtered-search quality at scale start eating your Postgres box — Qdrant is the move because it keeps you self-hosted and in control while giving you a purpose-built index and first-class payload filtering, rather than trading Postgres for someone else's cloud bill." featured: false tldr: "pgvector wins as long as your embeddings belong inside a transaction with the row they describe — that's a design advantage, not a stopgap. The graduation signal is not a recall number; it's your Postgres box spending its budget on vector index maintenance instead of your application. Qdrant is the natural next store because it is a dedicated engine you still run yourself: purpose-built HNSW, payload filtering that stays fast under selective constraints, and horizontal sharding — without surrendering your data to a managed cloud. The dividing line is who should be paying the cost of your vector index: your primary database, or a system built to carry it." keyTakeaways: - "pgvector's edge is transactional: the embedding and its source row commit together, so they can never silently disagree. That's worth keeping until it costs you." - "The signal to move is operational — index rebuild time, memory contention, and filtered-query latency degrading your primary workload — not a benchmark you read somewhere." - "Qdrant is the graduation target for teams who want to stay self-hosted: a dedicated index and rich payload filtering without handing your corpus to a managed provider." - "Moving to Qdrant means owning a sync path between Postgres rows and Qdrant points, and losing single-transaction consistency. Do it when the database is telling you to, not on day one." faqs: - q: "When should I move from pgvector to Qdrant?" a: "When vector index maintenance starts competing with your application for the same Postgres resources — slow HNSW rebuilds, memory pressure, or filtered vector queries dragging down transactional latency. Those are metrics on your own box, not thresholds from an article. If pgvector is quietly serving your corpus, moving is premature." - q: "Is Qdrant better than pgvector for filtered search?" a: "For heavy, selective payload filtering at scale, Qdrant's filtering is built into the vector index rather than bolted onto it, so it tends to hold quality where a Postgres WHERE clause plus an approximate index can fight each other. But pgvector's filters are ordinary SQL joins against your real schema, which is simpler and strictly consistent until scale changes the math." - q: "Can I run Qdrant self-hosted instead of using a managed vector cloud?" a: "Yes — that's Qdrant's appeal as the step up from pgvector. It's an open-source engine you deploy and operate yourself, so you gain a purpose-built vector store without surrendering your data to a managed provider or taking on usage-metered pricing. You do take on operating a second stateful system." --- 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 `WHERE` combined 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](/compare/pgvector-vs-pinecone): 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](/compare/pinecone-vs-weaviate-vs-qdrant) 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](/compare/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.