Qdrant vs. pgvector: which vector database for RAG?

Have a RAG knowledge system built on your own infrastructure? WZ-IT builds and operates RAG systems - including the right vector database, retrieval logic and permissions, GDPR-compliant from one team. See custom RAG solutions

Every RAG system needs a vector database to make the knowledge from documents searchable. Two options dominate the open-source space: the Postgres extension pgvector and the dedicated vector database Qdrant. They represent two approaches - staying in familiar Postgres or operating a specialized system. This comparison places both. As of July 2026.

Table of contents

• Dedicated vector database or Postgres extension
• pgvector: staying in Postgres
• Qdrant: built for vector search
• The two compared
• Which for which case

Dedicated vector database or Postgres extension

The fundamental question is not "which tool is better" but "your own system or extend the existing database". pgvector brings vector search as an extension into an existing PostgreSQL - no additional service, the same database. Qdrant is a standalone system written in Rust, built exclusively for similarity search.

Both are open source and self-hostable. The difference lies in the operating model, scaling and how deeply the vector search is intertwined with the rest of the data.

pgvector: staying in Postgres

pgvector is the pragmatic start for most first RAG pipelines. Because it lives in an existing Postgres database, operating an additional service is unnecessary: backups, monitoring, failover and access control all run through the existing Postgres installation.

The second advantage is consistency: when search results and application data lie in the same database, a whole class of synchronization bugs disappears. For typical sizes - roughly under ten million vectors - pgvector is fast enough, and with extensions like pgvectorscale it scales further. The storage foundation matters: the search benefits strongly from fast NVMe SSDs.

Qdrant: built for vector search

Qdrant is optimized for vector search from the ground up. The Rust implementation uses SIMD-accelerated distance calculations, memory-mapped storage and a search engine tailored to nearest-neighbor queries. In benchmarks Qdrant pulls ahead with large vector volumes (from about ten million) and high query concurrency and offers the best price-performance ratio in self-hosting.

Especially relevant for enterprise knowledge systems: Qdrant applies payload filters directly during the similarity search (filterable HNSW). That is the basis for permission-controlled RAG, where forbidden hits must not even enter the result set - see RAG with real permissions. The price is a separate service with its own storage, monitoring and upgrade path.

The two compared

Which for which case

The honest short version: when in doubt, start with pgvector. Anyone already using Postgres with a manageable number of documents saves a whole service with pgvector and gets consistency for free.

• pgvector when you operate Postgres anyway, the data volume stays in the low millions and simplicity and consistency matter.
• Qdrant when the vector volume or the query concurrency grows considerably, or when demanding filters - for tenant separation and permissions - must take effect directly and quickly in the search.

A switch stays possible: the embeddings are independent of the storage engine, the corpus can be re-indexed into Qdrant. That is why the smarter path is often to start small and switch only when the requirements demand it. How the vector database fits into the overall picture is shown in What is RAG?.