Qdrant vs pgvector: Which Vector Search to Use

Qdrant vs pgvector in one sentence: use pgvector if you already run PostgreSQL and vector search is a feature of your app, and move to Qdrant once vector count, query throughput, or filter complexity make vector search a workload in its own right. Qdrant is a purpose-built, open-source vector database engineered for large-scale, high-throughput, heavily-filtered similarity search. pgvector is a PostgreSQL extension that gives your existing database a vector type and similarity search so embeddings live right beside your relational data. The rest of this post backs that verdict up with published benchmark numbers and their caveats, the scaling signals that tell you pgvector is running out, an operational cost breakdown, and a verdict by workload profile.

If your starting point is Postgres and you are also weighing the lightweight option, our Chroma vs pgvector comparison is the natural next read. This page goes deep on just Qdrant and pgvector for searchers who have already shortlisted those two.

The short answer

• Pick Qdrant if you need a purpose-built vector database for large-scale, high-throughput similarity search with rich payload filtering, quantization, and distributed sharding - performance and scale are the priority.
• Pick pgvector if you already run PostgreSQL and want to add vector search to it, keeping embeddings, metadata, and relational data in one system with full SQL, transactions, and your existing backup and ops tooling.
• Use both in stages or by workload: start on pgvector to ship fast inside Postgres, then move large or hot collections to Qdrant once scale, throughput, or filtering complexity outgrows your primary database.

The rule: choose Qdrant when vector search is the workload, choose pgvector when vector search is a feature of a system you already run.

Verdict by workload profile

Generic advice is easy to agree with and hard to act on. Find the profile closest to yours and take the verdict.

If your profile is not on this list, the default is pgvector when Postgres is already there, because the cheapest system is the one you are already operating. Move when the signals in the scaling section below start firing, not before.

What each tool is

Qdrant is an open-source, dedicated vector database written in Rust and licensed under Apache-2.0, available self-hosted or as the managed Qdrant Cloud. It is built purely for high-performance similarity search at scale. Its defining features are vector-native: HNSW indexing for fast approximate nearest-neighbor search, rich payload filtering applied during the vector search rather than as a post-filter, scalar and binary quantization to shrink memory footprint and speed up queries, and distributed sharding for horizontal scale. Because vectors are its only job, Qdrant optimizes hard for throughput, recall, and memory efficiency on large collections.

pgvector is an open-source PostgreSQL extension that adds a vector data type and similarity search to an existing Postgres database. You install it, declare vector columns, and query with standard SQL using distance operators, backed by HNSW and IVFFlat indexes for approximate nearest-neighbor search. The defining advantage is that embeddings live alongside your relational data: you join vectors to business tables, wrap writes in transactions, and reuse the Postgres backup, replication, and monitoring tooling you already operate. The trade-off is that Postgres is a general-purpose database, so at very large vector counts or high query throughput a dedicated engine generally pulls ahead.

Qdrant vs pgvector: head-to-head

A few of these dimensions deserve unpacking.

Architecture and operations. This is the headline difference. Qdrant is a separate service you run and scale on its own terms, which is exactly why it can specialize so hard on vector performance. pgvector adds vectors to a database you already operate, so there is no new system to provision, monitor, or back up - the marginal cost is the extra storage and compute for the vectors. If you already run Postgres well, pgvector is the lighter operational lift; if you do not, Qdrant may actually be the simpler thing to stand up because it is built for exactly this.

Filtering. Both can filter, but they filter differently. Qdrant applies rich payload filtering during the vector search, so complex predicates and high-cardinality filters stay fast even on large collections. pgvector filters with standard SQL WHERE clauses on columns, which is expressive and familiar but can get less efficient as filters and vector counts grow. For heavily-filtered semantic search at scale, Qdrant is the lower-friction path.

Scale and performance. Qdrant is built for large-scale, high-throughput workloads: HNSW plus scalar and binary quantization keep memory and latency down, and distributed sharding lets you scale horizontally. pgvector scales with your Postgres instance and performs well up to moderate scale, but pushing it to very high vector counts or query rates means scaling Postgres itself, which is harder than scaling a purpose-built engine.

Data model. pgvector’s superpower is that embeddings live next to your relational data. You join a vector search directly to user, product, or document tables, enforce constraints, and wrap everything in transactions - no syncing between two systems. Qdrant keeps vectors and their payloads in a separate store, which is cleaner for pure vector workloads but means your relational source of truth lives elsewhere.

What the published benchmarks actually show

Be careful with Qdrant vs pgvector benchmarks. Nearly every number you will find online was published by a vendor, on their hardware, with their tuning, against a version of the other tool that has since moved. Here is what genuinely exists, with the caveats attached.

The 50 million vector test, run by Timescale (now TigerData). The most substantial public comparison used 50 million Cohere embeddings at 768 dimensions, running both systems on AWS r6id.4xlarge instances (16 vCPU, 128 GB RAM, local NVMe) via a fork of the open-source ANN-Benchmarks framework modified to measure parallel throughput. At a 99% recall target, Qdrant held the lower tail latency: p50 30.75 ms vs 31.07 ms, p95 36.73 ms vs 60.42 ms, and p99 38.71 ms vs 74.60 ms. Postgres won throughput decisively at 471.57 QPS against Qdrant’s 41.47 QPS, an 11.4x gap. At a 90% recall target both stayed under 20 ms across percentiles, with Postgres at 1,589.79 QPS against Qdrant’s 360.81 QPS. Index build time went the other way: 3.3 hours for Qdrant against 11.1 hours for Postgres. (TigerData)

Two caveats matter more than the numbers themselves. First, TigerData publishes pgvectorscale and has an obvious stake in the outcome. Second, and more important for your decision: the Postgres side ran pgvector plus pgvectorscale, not stock pgvector. pgvectorscale adds a StreamingDiskANN index and Statistical Binary Quantization on top of pgvector. If you are on a managed Postgres that does not offer that extension, this benchmark is not describing your deployment.

The 1 million vector test, June 2023. Widely quoted and now largely obsolete. On a single t3.2xlarge using the dbpedia-entities-openai-1M dataset, Qdrant came out roughly 15x ahead on throughput and about 18 points ahead on retrieval accuracy (around 100% against pgvector’s ~82% on k-NN). The catch: the test ran in June 2023, and pgvector did not ship HNSW indexing until version 0.5.0 in August 2023. That was IVFFlat-era pgvector. Treat those figures as a historical data point, and be skeptical of any 2026 article that quotes them without the date. (Nirant Kasliwal and Kumar Shivendu)

Qdrant’s own benchmark suite. Qdrant publishes public single-node benchmarks across four datasets on Azure, comparing itself to Elasticsearch, Milvus, Redis, and Weaviate. Worth knowing: pgvector is not included, and the single-node results were last refreshed in 2024. (Qdrant benchmarks)

The honest summary: there is no neutral, current, apples-to-apples public benchmark of stock pgvector against Qdrant. What the evidence supports is a shape rather than a ratio. Qdrant tends to win tail latency and index build time. Postgres with the right index extension can win raw throughput. And the gap has narrowed with every pgvector release since 0.5.0. That is exactly why the rest of this guide decides on operating model and scale signals rather than on someone else’s leaderboard, and why you should reproduce any number that matters to you on your own corpus, your own filters, and your own hardware before it drives a migration.

When pgvector stops being enough

There is no magic vector count where pgvector falls over. There is a set of signals, and in practice they show up in roughly this order.

1. Your HNSW index stops fitting in memory. This is almost always the first cliff, and it arrives as a latency problem rather than an error. A 1536-dimension embedding stored as float32 is 6 KB per vector before any index overhead, so 10 million of them is over 60 GB of raw vector data alone. Once the index plus your hot working set exceeds what the instance can hold in shared buffers and the OS page cache, p99 latency jumps as queries start reading from disk.
2. Index builds become an operational event. HNSW builds are CPU and memory hungry and bounded by maintenance_work_mem. When rebuilding after a re-embedding takes hours and has to be scheduled into a maintenance window, changing embedding models stops being a routine decision. Qdrant’s faster builds are a real advantage here, as the 50M benchmark above shows.
3. Filtered queries get unpredictable. pgvector 0.8.0 (October 2024) added iterative index scans precisely because a filtered ANN query could return too few rows, an issue known as overfiltering. You enable it with hnsw.iterative_scan or ivfflat.iterative_scan, bounded by hnsw.max_scan_tuples, and it helps a great deal. But heavy, high-cardinality filtering is where Qdrant’s during-search payload filtering is architecturally ahead, and the symptom you feel is variable latency rather than a clean failure.
4. Vector queries start hurting your OLTP workload. Vector search competes for the same shared buffers, CPU, and autovacuum attention as the rest of your database. The moment a slow semantic search degrades checkout, login, or a reporting job, vector search has stopped being a harmless feature of your primary database.
5. You need to scale out rather than up. Postgres scales vectors vertically. Read replicas add read throughput but every replica carries a full copy of the index, so your memory bill multiplies. Qdrant shards a collection across nodes, which is a different and cheaper curve once you are past a single machine.
6. Write churn bloats the index. Frequently updated or deleted embeddings leave HNSW graphs in progressively worse shape, and the standard Postgres answer is a rebuild you have already decided is expensive. High-churn corpora are one of the clearest “leave Postgres” signals.

Try these before you migrate

Migration is a real project, so exhaust the cheap headroom first, roughly in this order:

Plenty of teams find another two to five times of headroom in that list without ever leaving Postgres. When the levers are exhausted and the signals above are still firing, that is the moment to move the hot collections to Qdrant, and not a release earlier.

When to choose Qdrant

Qdrant wins when vector search is the workload, not a side feature. Choose it when:

• You are running large-scale similarity search with millions or more vectors and need consistent low latency.
• Your workload is high-throughput and you want a system tuned end to end for query performance.
• You need rich payload filtering applied during search, not bolted on afterward.
• You want quantization (scalar or binary) to cut memory cost and speed up search on big collections.
• You need to scale horizontally with distributed sharding rather than scaling a single database.
• You do not already run Postgres at the required scale, so a dedicated vector engine is the cleaner thing to operate.

In short, Qdrant is the default when performance, scale, and advanced filtering matter most, and a separate vector service is a fair trade for that.

When to choose pgvector

pgvector wins when you already run Postgres and want to avoid a new system. Choose it when:

• You already operate PostgreSQL and want vector search without adding another database to your stack.
• You want embeddings next to your relational data so you can join vectors to business tables in plain SQL.
• You need transactions that span vectors and your existing data, with full Postgres ACID guarantees.
• You value one backup, one monitoring setup, one connection pool instead of operating two systems.
• Your scale is small to moderate - large enough to need real ANN indexing, not so large that Postgres becomes the bottleneck.
• You want the simplest path to production by enabling an extension rather than standing up a service.

In short, pgvector is the pick when vector search is a feature of an app you already run on Postgres, and one unified system beats a dedicated engine.

Can you use them together?

Often you pick one per workload, but a staged pattern is common and sensible. The typical path is to start with pgvector - ship retrieval fast inside the Postgres you already run, with embeddings joined to your relational data - and then move large or hot collections to Qdrant once vector count, throughput, or filtering complexity outgrows what you want to put on your primary database. You can also split by workload: keep small, transactional, tightly-joined vector data in pgvector and push high-traffic, heavily-filtered semantic search to Qdrant. If you are still deciding between the dedicated engines themselves, our Qdrant vs Weaviate comparison covers that side of the field.

Whichever you choose, the vector store is only one layer. Retrieval quality depends just as much on your chunking, embedding model, and the quality of the corpus you index - which is why we recommend validating any choice on your own data, not vendor benchmarks.

Operational cost comparison

Neither tool is priced the way managed-SaaS vector databases are, so the cost story is about operating model, not a sticker. pgvector adds near-zero licence cost - it is an open-source extension - and its real cost is the extra compute and storage for vectors inside a Postgres instance you already pay for. Qdrant is open-source too (Apache-2.0), so self-hosting costs you compute, storage, and the engineering time to operate it, with Qdrant Cloud as a managed alternative. With licences off the table, the actual bill comes down to three things: memory, compression, and people.

Memory is the dominant infrastructure cost on both sides

Start with the arithmetic, because it drives everything else. Raw float32 storage per vector, before any index structure, payload, or row overhead:

Those are floors, not estimates. Add the HNSW graph, payload or column data, and per-row overhead, and real footprints run meaningfully higher. This table is why compression is the cost conversation in vector search, and why the two tools’ compression stories are worth comparing directly.

Compression levers, compared

Qdrant treats this as a first-class feature: scalar quantization to int8 for roughly a 4x reduction, binary quantization for up to 32x on embeddings that tolerate it, and on-disk or memory-mapped storage so cold vectors do not have to be resident. Qdrant 1.18 (May 2026) added TurboQuant, a method from Google Research that applies a fast Hadamard rotation before compression so values spread evenly across coordinates. Qdrant reports similar recall and speed at roughly twice the compression ratio of scalar quantization, and because the rotation is model-agnostic it works without per-dataset tuning. Qdrant 1.16 added tiered multitenancy and disk-efficient vector search in the same direction.

pgvector has fewer knobs but more than it gets credit for. halfvec (2-byte floats, added in 0.7.0 in April 2024) roughly halves vector storage and raises the indexable ceiling to 4,000 dimensions. Binary vectors using the native bit type, with hamming_distance and jaccard_distance, push storage down much further and are indexable to 64,000 dimensions. Expression indexes let you quantize at index time while keeping full-precision vectors in the table for reranking. And pgvectorscale adds StreamingDiskANN, which keeps part of the index on disk, plus Statistical Binary Quantization. The gap is real but narrower than the “Postgres cannot quantize” version of this comparison suggests.

People cost is the one teams underestimate

A second datastore is not a line item, it is a set of ongoing obligations: provisioning, version upgrades, backup and restore that someone has actually rehearsed, monitoring and alerting, on-call coverage, access control, and a sync pipeline that keeps Qdrant consistent with your relational source of truth. That last one is the sleeper. Dual-write and CDC pipelines fail quietly, and you usually discover the drift through bad retrieval quality rather than through an alert. pgvector avoids every one of those obligations by not adding a system.

When Qdrant is genuinely the cheaper option

Past a certain scale the maths flips. Quantization plus a memory layout designed for vectors lets Qdrant serve the same corpus on smaller machines, and it spares you from oversizing your primary Postgres just to hold an index. Scaling the database your whole business runs on is expensive and has a large blast radius; scaling a dedicated search service does not. If vector search is driving your Postgres instance size, you are already paying the Qdrant migration cost, just in the wrong currency.

Common pitfalls

• Reaching for a dedicated engine too early. If you already run Postgres and your scale is moderate, standing up Qdrant adds a system to operate that pgvector would have handled. Match the tool to your actual scale, not your aspirational one.
• Pushing pgvector past its comfort zone. At very high vector counts or query rates, scaling Postgres to keep up is harder than scaling a purpose-built engine. Watch latency and index build times, and plan the move to Qdrant before it hurts.
• Ignoring filtering cost. Heavily-filtered search behaves very differently between the two. Test your real filter predicates, not just plain nearest-neighbor queries, because that is where Qdrant’s during-search payload filtering shows its value.
• Skipping quantization tuning. Qdrant’s scalar and binary quantization can dramatically cut memory and cost, but they trade off recall. Measure recall on your own data rather than assuming defaults are fine.
• Trusting vendor benchmarks over your corpus. Index type, distance metric, and corpus quality move retrieval results more than the headline benchmark numbers. Validate on your own data before committing.

Related reading

• Chroma vs pgvector - the lightweight embedded option versus Postgres for vector search.
• Qdrant vs Weaviate - two purpose-built vector databases head to head.
• Pinecone vs Milvus - managed SaaS versus open-source at scale.

Getting help

Qdrant vs pgvector is the right first question, but the bigger lever is whether your whole retrieval stack - vector store, embedding model, chunking, and corpus quality - is set up to deliver the answers your users need. We help AI teams pick the right vector layer and prove it works on their own data before it ships.

Start with a Data Quality Audit to check the embeddings and corpus feeding your retrieval layer, or an AI QA Readiness Assessment to find the gaps and risks across your AI stack. Book a free scope call.