pgvector vs Qdrant: Which Should You Use in 2026?
pgvector vs Qdrant compared: index types, filtering, scale and speed. A neutral decision guide for whether your Postgres is enough or you need Qdrant.
TL;DR - Already run Postgres and have under ~1M vectors? Use pgvector. Need heavy metadata filtering, quantization, hybrid search, or scaling past one node? Use Qdrant. - pgvector is a Postgres extension (one database, SQL and vectors together). Qdrant is a standalone vector database written in Rust. - Both use HNSW indexes. Raw-speed claims are config-dependent, and no neutral benchmark settles it. - The answer tends to flip once you pass a few million vectors or filtering dominates your queries.
If you already run Postgres and need vectors for RAG at modest scale, pgvector is usually enough. Choose Qdrant when you need heavy metadata filtering, quantization to cut memory, hybrid search, or horizontal scaling past a single node. Both use HNSW, so the decision is operational, not purely about speed.
That is the short version of pgvector vs Qdrant. The rest explains where each one wins and where the honest uncertainty lives.
What is the difference between pgvector and Qdrant?
pgvector is an open-source extension that adds a vector column type and similarity search to PostgreSQL. You keep one database. Your embeddings live next to your relational data, and you query both with SQL. It supports HNSW and IVFFlat indexes, with HNSW added in version 0.5.0 (August 2023). The latest release is 0.8.6 (July 2026).
Qdrant is a purpose-built vector database written in Rust. It runs as its own service with a REST and gRPC API. It uses HNSW as its only dense-vector index, but adds quantization, payload (metadata) indexing, hybrid search, and distributed deployment. The latest release is 1.19.2 (October 2026).
The core tradeoff: pgvector means one less system to run; Qdrant means a system built only for vectors.
| Dimension | pgvector (0.8.6) | Qdrant (1.19.2) |
|---|---|---|
| Type | PostgreSQL extension | Standalone vector database (Rust) |
| Index support | HNSW and IVFFlat | HNSW (dense); sparse index for sparse vectors |
| Filtering | SQL WHERE; post-filters after index scan unless iterative scans are on |
Filterable HNSW — filters applied during graph traversal via payload indexes |
| Quantization | halfvec (half precision), binary quantization via expression index |
Scalar, binary, product (plus TurboQuant) |
| Scaling | Scales with your Postgres instance (vertical, read replicas) | Horizontal sharding and replication (distributed) |
| Hosting | Anywhere Postgres runs; most managed Postgres services | Self-hosted or Qdrant Cloud |
| Best for | Existing Postgres users, RAG at modest scale, SQL + vectors together | Large vector counts, heavy filtering, memory-constrained or hybrid search |
Which is faster?
Honest answer: it depends on your config, and no neutral benchmark settles it. Both engines use HNSW, and HNSW performance is driven by parameters (m, ef_construction, ef_search), dataset size, dimensionality, and how much filtering you do. A widely shared Medium post argues the two are roughly the same speed; that is defensible at small scale with comparable tuning.
Where the picture changes is filtering and memory. Qdrant’s filterable HNSW applies filters during graph traversal, so a query like “nearest vectors where tenant_id = X” stays fast. pgvector applies filters after the approximate index scan by default, so a selective filter can shrink your result set unless you enable iterative index scans (added in 0.8.0). Qdrant’s quantization (down to binary, cutting memory roughly 32x) also lets it hold more vectors in RAM, which matters past a few million.
Treat vendor benchmarks with caution. Qdrant’s own benchmark page claims it “achieves highest RPS and lowest latencies in almost all scenarios,” but it is vendor-run, self-admittedly biased, and does not even include pgvector. Benchmark claims are config-dependent. Test on your own data before you decide.
When should you use each?
Use pgvector when Postgres is already your source of truth and you want to avoid running a second database. Use Qdrant when vector search is a first-class workload with its own scale, filtering, and memory demands. This is the real “do you need Qdrant or is pgvector enough” question, and it usually comes down to scale and filtering, not raw latency.
Can pgvector replace a dedicated vector database?
For many teams, yes. If you are building RAG on top of data that already lives in Postgres, pgvector with an HNSW index handles hundreds of thousands to low millions of vectors well, and you keep transactional guarantees, joins, and backups you already have. The “pgvector or Qdrant” choice only forces itself once your vector workload outgrows what one Postgres instance comfortably serves — the point at which a dedicated vector database earns its keep.
What this means for you
If you already run Postgres and have under ~1M vectors: Start with pgvector. Add the extension, create an HNSW index, and move on. You avoid a second system, and for most RAG apps the performance is fine. Revisit only if queries slow down or memory gets tight.
If you need heavy metadata filtering or hybrid search: Lean toward Qdrant. Filterable HNSW keeps selective filters fast, and native hybrid (dense + sparse) search is built in. pgvector can filter with SQL, but post-filtering and index interplay get fiddly as selectivity rises.
If you’re scaling past a single node: Choose Qdrant. Horizontal sharding, replication, and quantization are designed for large, memory-heavy collections. pgvector scales with your Postgres box and read replicas, which has a ceiling.
If you’re unsure: Default to pgvector. It is the cheaper decision to reverse, and it keeps your embeddings beside the relational and NoSQL data stores you already operate. Migrating out of Postgres later is easier than running a Qdrant cluster you did not need.
Frequently Asked Questions
What is the difference between pgvector and Qdrant?
pgvector is a PostgreSQL extension that adds vector search to a database you may already run, keeping SQL and embeddings in one place. Qdrant is a standalone vector database written in Rust, with quantization, filterable HNSW, hybrid search, and horizontal scaling. One reuses Postgres; the other is purpose-built.
Is Qdrant faster than pgvector?
Sometimes, but it depends on configuration. Both use HNSW, so tuned similarly at small scale they can be comparable. Qdrant tends to pull ahead on heavily filtered queries and memory-constrained workloads thanks to filterable HNSW and quantization. Qdrant’s own benchmarks are vendor-run and exclude pgvector, so verify on your own data.
When should you use pgvector vs Qdrant?
Use pgvector when you already run Postgres and have up to a few million vectors, and want one database for SQL and vectors. Use Qdrant when you need heavy metadata filtering, quantization to cut memory, hybrid search, or horizontal scaling across nodes. Scale and filtering decide it, not raw speed.
Can pgvector replace a dedicated vector database?
For many RAG and search workloads, yes. If your data already lives in Postgres and you have under roughly a million vectors, pgvector with an HNSW index is usually enough, and you keep joins, transactions, and existing backups. You outgrow it mainly at large scale or with demanding filtering.
Editor’s note — sources: pgvector CHANGELOG (github.com/pgvector/pgvector) — latest 0.8.6 (2026-07-29), HNSW added in 0.5.0, iterative index scans in 0.8.0; pgvector README (github.com/pgvector/pgvector) — index types and filtering behavior; Qdrant releases (github.com/qdrant/qdrant) — latest 1.19.2 (Oct 2026); Qdrant indexing docs (qdrant.tech) — filterable HNSW; Qdrant quantization docs (qdrant.tech) — scalar/binary/product quantization; Qdrant benchmarks (qdrant.tech) — vendor-run, excludes pgvector. Versions verified 2026-10-22.