pgvector vs Qdrant for a 10M-chunk index: how I chose

Six months ago, our hybrid search setup was burning money and dropping queries. We were serving RAG-augmented financial reports over a dataset of 10 million text chunks (768-dimensional embeddings generated via text-embedding-3-small down-projected, plus structured metadata like ticker, timestamp, doc_type, and compliance_level).

We started with PostgreSQL using pgvector because our relational data lived there. It was clean, familiar, and required zero extra infra. But as the index crossed 8 million vectors, our tail latencies blew up. Filters combined with vector distance operators caused catastrophic query plan degradation.

I spent three weeks benchmarking pgvector (v0.6.0 with HNSW) directly against a dedicated vector database, Qdrant (v1.8.0), under a sustained load of 500 QPS with tight metadata filtering. Here is the engineering reality of scaling both to 10 million chunks, where pgvector choked, how Qdrant handled the load, and how I structured our final architecture.

The Problem: The Filtered HNSW Trap

Vector search without filtering is easy. Vector search with strict dynamic filters at scale is where systems break.

In our workload, every query includes at least two metadata payloads:
1. An exact match on org_id (tenant isolation).
2. A range filter on timestamp (e.g., last 90 days).

In pgvector, when you build an HNSW index on a vector column, the index graph is constructed independently of your relational columns. When you issue a query like this:

Postgres has to choose between two terrible execution plans:

1. Iterate the HNSW graph first: It traverses the nearest neighbors in vector space and checks if each node satisfies the WHERE clause. If your filter is restrictive (e.g., matching 1% of rows), the engine traverses tens of thousands of invalid graph nodes before finding 10 matches. Query times jump from 12ms to 4,200ms.
2. Scan the relational index first: It uses a B-tree index on (org_id, created_at) to collect matching rows, then performs an exact brute-force cosine distance calculation across those matches. If the filter matches 100,000 rows, it computes 100,000 high-dimensional vector distances on the fly. CPU usage spikes to 100%.

Here is the exact Postgres execution plan where pgvector gave up on the HNSW index due to low metadata selectivity, defaulting to an index scan followed by a costly top-N sort:

382 milliseconds for a single query at 50 QPS saturation meant our API nodes were choking on connection pools. We needed payload-aware HNSW indexing.

Architecture: Hybrid Ingestion and Search

To fix this, we decoupled our vector search engine from our primary relational store, introducing Qdrant alongside PostgreSQL. Postgres remained the source of truth for raw text and normalized entities, while Qdrant held vectors and payload indices for low-latency retrieval.

flowchart LR
 client["API Gateway"]
 pg["PostgreSQL DB"]
 qdrant["Qdrant Engine"]
 embed["Embedding Worker"]

 client -->|"1. Write Payload"| pg
 pg -->|"2. Trigger Event"| embed
 embed -->|"3. Upsert Vector"| qdrant
 client -->|"4. Filtered Query"| qdrant
 qdrant -->|"5. Return IDs"| client

This decoupled pattern allowed Qdrant to run single-stage payload filtering during graph traversal using payload bitsets, avoiding both the graph-traversal post-filtering problem and the brute-force pre-filtering problem.

Benchmarking Setup and Code

I built a reproducible benchmark harness in Python to populate 10,000,000 chunks (768 dimensions) into both engines, running on an AWS r6i.4xlarge instance (16 vCPUs, 128 GB RAM, NVMe storage).

1. PostgreSQL + pgvector Setup

First, we set up the pgvector schema using an HNSW index with m=16 and ef_construction=64.

To ingest vectors at scale into Postgres without crashing memory, we used pgcopy with binary format batching:

2. Qdrant Setup

For Qdrant, we initialized a collection configured with HNSW parameters matching our vector dimensions, using scalar quantization (int8) to compress the RAM footprint of 10 million vectors.

Batch ingestion into Qdrant using the parallel gRPC uploader:

Results: Performance, RAM, and Latency Metrics

We ran a concurrent search benchmark using Locust, simulating 500 active threads running mixed queries. 30% of queries were pure vector searches, while 70% included dynamic metadata filters (org_id match + created_at timestamp range filter).

Query Latency & Throughput (10M Chunks, 768 Dimensions)

Here is an actual trace log from our benchmark running against Postgres under load:

And the corresponding Qdrant search block executed concurrently under the same load:

Lessons Learned & What I Chose

pgvector is a great tool for early-stage applications. If your dataset is under 2 million vectors, or if your queries rarely use metadata filters outside your vector index, staying in Postgres reduces operational complexity.

However, at 10 million chunks with heavy metadata filtering, pgvector broke under production stress. The lack of payload-aware index graph filtering forced Postgres into costly plan switches that degraded latency by 100x.

We ultimately chose Qdrant for vector storage and retrieval, keeping primary metadata and core entities in PostgreSQL.

Summary of Decisions:

1. Use Qdrant if:
2. You operate at scale (>5M vectors) with dynamic, tenant-isolated, or range-based metadata filters.
3. You need memory optimization techniques like scalar quantization (int8) or product quantization out of the box.

4. Tail latency (p99) under 50ms is a hard service-level objective (SLO).

5. Use pgvector if:

6. Your vector dataset fits comfortably in memory (<2M chunks) and metadata filtering is minimal.
7. You cannot add another infrastructure component to your operational stack.
8. Transactional consistency (ACID) across relational data and vector writes is a strict requirement.