Qdrant vs. pgvector: choosing a vector database for self-hosted RAG
AI-generated, human-reviewed
Every RAG project starts with an architecture decision that is hard to reverse later: where do the vectors live? For a system on your own infrastructure, the two obvious options are Qdrant and pgvector. Both can be self-hosted, both provide similarity search over embeddings — and yet they lead to noticeably different systems. This article frames the Qdrant vs. pgvector choice along the criteria that actually matter in operation, not along feature lists.
For context: in a Retrieval-Augmented Generation (RAG) system, documents are split into chunks, stored as embeddings, and retrieved at query time by semantic similarity to the user’s question. The vector store is the component that performs this retrieval. Its choice matters less for raw hit quality — that depends more on chunking, the embedding model, and the retrieval strategy — than for filtering, the scaling path, and the operational cost you carry over time.
What the choice really comes down to
The underlying search algorithm barely separates the two: both use approximate nearest-neighbor search over an HNSW index and deliver good results for typical knowledge bases. So the relevant question is not “which database searches better” but “which one fits your existing landscape and operating model.”
Two factors dominate. First: do you already run PostgreSQL? Then the question is whether a second stateful system justifies the gain. Second: how demanding are filtering, hybrid search, and scaling in your use case? The closer vector search sits to the core of your product, the more specialization pays off.
pgvector — an extension of your Postgres landscape
pgvector is an extension for PostgreSQL. It adds a vector data type and matching indexes — the vectors sit as a column in an ordinary table. That gives you the full power of SQL: you filter metadata with WHERE, join vector hits to relational data with JOIN, and everything runs in the same transactions as the rest of your application.
The real advantage is operational: no additional system. If you already back up, monitor, and patch Postgres, you get vector search without a new component in the stack. A document and its embeddings stay consistent because they live in the same database — no reconciling two stores, no question about which version is current.
The limits show up as the corpus grows and filtering gets more complex. pgvector inherits Postgres’s scaling model: primarily vertical, on a single node. Very large vector sets or heavy filters hit those limits sooner than a system built for exactly that load.
Qdrant — the specialized vector database
Qdrant is a dedicated vector database. It stores a structured payload alongside each vector and is designed from the ground up to filter during the similarity search — with its own indexes on payload fields. That matters when you restrict large corpora by metadata such as tenant, time range, or permission while keeping response time and hit quality.
Hybrid search — combining dense (semantic) and sparse (keyword-based) retrieval — is supported natively, including fusion of the result lists. For horizontal scaling, Qdrant ships with sharding and replication, so the path to very large corpora is mapped out.
The price of that specialization is a second stateful system. It needs to be operated, monitored, backed up, and upgraded — on its own release cycle and without transactional coupling to your relational data. You have to establish consistency between primary data and vectors yourself, typically through your ingestion pipeline.
Decision criteria: Qdrant vs. pgvector
The table below contrasts the criteria that tip the balance in practice. Read it qualitatively — the concrete threshold depends on your corpus, your hardware, and your latency requirements.
| Criterion | pgvector | Qdrant |
|---|---|---|
| Filtering & metadata | Full SQL (WHERE, JOIN); filter performance limited on large corpora | Payload indexes, filtering during search; built for large, filtered corpora |
| Hybrid search | Combinable via Postgres full-text search, but hand-built | Native (dense + sparse vectors, fusion) |
| Scaling | Primarily vertical, Postgres model | Horizontal via sharding & replication |
| Operational effort | No new component if Postgres is running | Additional system to run and monitor |
| Backup & upgrades | Postgres standard (pg_dump, PITR), one cycle | Own snapshots, own release cycle |
| Postgres integration | Native, transactional, shared queries | Separate store; maintain IDs/consistency yourself |
GDPR & data sovereignty
On data sovereignty, little separates the two. Both can be self-hosted — on your servers, in your data center, or in an environment you control. Embeddings, documents, and the search index never leave your infrastructure, and no data flows into a third-party cloud. That is the basis of a GDPR-compliant architecture and the reason we recommend running vector stores in-house by default.
One detail to consider early: the right to erasure. When a document is removed, its embeddings and payloads have to go too. Both systems support targeted deletion — in pgvector as a DELETE within the transaction, in Qdrant via the points API. What matters is that your pipeline reliably triggers the deletion. The choice of store changes little here; it should not become an excuse to defer the topic.
Recommendation by starting point
There is no blanket winner — the right choice follows your starting point.
- You already run Postgres, the corpus is manageable, the filters are simple: pgvector. One system fewer, transactional consistency, the lowest operational overhead. For many internal knowledge assistants, this is the sensible first choice.
- Large or fast-growing corpora, demanding metadata filters, a genuine need for hybrid search or horizontal scaling: Qdrant. Specialization pays off where vector search becomes the core load.
- You are unsure: start with pgvector and wrap retrieval behind a clear interface. That keeps a later switch to Qdrant a contained change rather than a rewrite.
The costliest mistake is not the “wrong” database but a retrieval layer wired so tightly that any switch hurts. Treat the vector store as a replaceable building block behind an abstraction — and the decision relativizes itself.
Takeaways
- Qdrant vs. pgvector is not a question of search quality but of operational fit and your scaling path.
- pgvector shines through simplicity and its native proximity to Postgres; Qdrant through filtering, hybrid search, and horizontal scaling — at the cost of a second system.
- Both are self-hosted and therefore suitable for sovereignty-sensitive, GDPR-compliant architectures.
- Wrap retrieval so the choice stays reversible.
If you are planning a RAG system meant to outlive the prototype — with evaluation, operations, and the right vector-store decision — you will find the frame under RAG systems for enterprise knowledge.