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 the internal assistant
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 October 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 (currently 0.9.1, with a hardened DiskANN index) it scales further. The storage foundation matters: the search benefits strongly from fast NVMe SSDs.
The current release is pgvector 0.8.7 from 1 October 2026. It fixes a buffer overflow during IVFFlat index builds (changelog). Anyone using IVFFlat should apply the update promptly.
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. In our assessment it is usually the more economical choice in self-hosting in these scenarios, because the same load needs less hardware.
Qdrant 1.19 (currently 1.19.2) added features that affect memory footprint in particular: TurboQuant can store vectors 4-bit quantized only, without keeping the original vectors on disk. The memory tiers cold, cached and pinned define per collection component what stays in RAM. On top come per-query IDF statistics for sparse search, for example separated by tenant, and prefix filters on keyword fields.
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
| Dimension | pgvector | Qdrant |
|---|---|---|
| Type | PostgreSQL extension | Standalone vector database |
| Operation | Part of the existing DB | Separate service (container/K8s) |
| Consistency | With application data in one DB | Separate system |
| Scaling | Good up to ~10M vectors | Strong from 10M+ and high concurrency |
| Filters | SQL conditions | Payload filters in the search (HNSW) |
| Operating effort | Uses existing Postgres infrastructure | Own storage, monitoring, updates |
| Sweet spot | First entry, moderate size | Large scale, demanding filters |
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?.
