Vector Database Benchmarks at Scale: pgvector vs. Qdrant for 100M+ Embedding Collections

An enterprise retrieval-augmented generation (RAG) application may perform well at one million embeddings, then encounter unpredictable p99 latency, cache misses, slower index construction, and memory contention as its corpus grows. Testing only a developer laptop or a small sample rarely exposes the effects of selective metadata filters, continuous updates, concurrent users, and hundreds of millions of records.

At this scale, enterprise vector database architecture is more than choosing a search engine. Embedding representation, index design, retrieval quality, hardware, transactional requirements, security boundaries, and total operating cost all shape the decision. Neither pgvector nor Qdrant has a universal failure threshold tied to vector count.

Quick Summary: pgvector vs. Qdrant: Which Is Better for Enterprise Vector Search?

pgvector integrates vector retrieval with PostgreSQL transactions and relational queries; Qdrant specializes in vector indexing, payload filtering, and quantization. For collections exceeding 100 million embeddings, neither is universally superior. Compare recall, latency, ingestion, infrastructure cost, and operational complexity under workloads.

1. The Scaling Challenge: Why Vector Search Gets Harder at 100M+ Embeddings

Memory requirements. At 100 million embeddings with 1,536 FP32 dimensions, each raw vector occupies 1,536 × 4 = 6,144 bytes. The resulting 614.4 GB (about 572.2 GiB) excludes identifiers, metadata, index graphs, temporary build space, replicas, database structures, and spare capacity. A sizing model must distinguish stored payload, index footprint, memory residency, and total cluster resources.

Index construction and ingestion. Hierarchical Navigable Small World (HNSW) is a graph-based approximate nearest-neighbor index. Building its neighbor graph consumes compute and memory; maintaining it during incoming writes can compete with search traffic. Bulk-loading strategy, background indexing, resource limits, and implementation determine the impact. Rebuilding an index does not universally mean all database writes stop.

Tail latency and filtering. p95 is the response time at or below which 95% of requests finish; p99 covers 99%. The slowest requests matter to interactive RAG, because a retrieval stall can delay the model response. Concurrency, cache warmth, filter selectivity, SSD access, and search breadth can affect these percentiles even when average latency appears stable.

2. pgvector vs. Qdrant: Architecture and Performance Comparison

pgvector is an extension for PostgreSQL with exact nearest-neighbor search and approximate HNSW and IVFFlat indexes. Qdrant is a dedicated search system with HNSW, payload indexing, vector quantization, and deployment features for distributed retrieval. Their different data models make integration cost a first-class design variable. 

The comparison is architectural, not a measured speed ranking. pgvector can be attractive when applications already depend on transactional joins and one operational platform. Qdrant can be attractive when dedicated retrieval features and workload isolation justify managing an additional system. Neither RAM utilization nor filtered-search speed can be predicted fairly from product category alone.

3. How to Benchmark pgvector vs. Qdrant at 100 Million Vectors

A valid pgvector vs. Qdrant benchmark must compare an identical workload and an agreed retrieval-quality target. Without an equivalent 100-million-vector test conducted under matched conditions, publishing fabricated queries-per-second or latency figures is worse than reporting a reproducible protocol.

·         Use identical vectors, dimensions, distance metrics, metadata, query samples, filter distributions, and top-k values; preserve tenant and document skew.

·         Document processor type, RAM, SSD/NVMe characteristics, network, replicas, software versions, topology, caching, and ingestion concurrency.

·         Tune and disclose HNSW construction/search parameters, IVFFlat settings where relevant, quantization, payload/SQL indexes, and resource budgets.

·         Measure recall@k: the fraction of true top-k neighbors recovered versus an exact-search ground truth, using a representative evaluation subset where exhaustive full-corpus search is impractical.

·         Report p50, p95, p99, throughput, load time, index-build time, update/deletion behavior, CPU, resident memory, disk I/O, storage, and monthly infrastructure cost.

·         Test broad and highly selective filters, steady reads, writes mixed with reads, cold and warm caches, and several fixed concurrency levels.

Compare configurations on a recall-latency frontier, not their fastest isolated response. Two systems returning different relevant documents at different recall levels are not interchangeable. A benchmark missing index settings, hardware, concurrency, filters, or recall cannot justify an enterprise procurement decision.

4. Four Technical Pillars of High-Scale Vector Retrieval

Pillar 1: Vector Quantization and Dimensionality Reduction

An FP32 component occupies four bytes; an 8-bit encoded component occupies one. For the vector payload alone, moving from 32-bit to 8-bit representation cuts nominal size by 75%, before indexes, quantization metadata, originals retained for rescoring, and other overhead. Quantization can change neighbor order and lower recall; the impact depends on embeddings, query mix, encoding method, and reranking or rescoring.

Dimensionality reduction is different: it decreases the number of dimensions rather than reducing bytes per dimension. Qdrant documents scalar, product, binary, and other quantization choices and their trade-offs; pgvector provides half-precision and binary-vector strategies, not an identical drop-in quantization implementation.

Pillar 2: Hybrid Search: Dense and Sparse Retrieval

Dense embeddings find semantically similar passages even with different wording. Sparse retrieval emphasizes tokens and can identify exact SKUs, error codes, proper nouns, and specialized domain terms that dense models may miss. A combined pipeline can fuse scores or ranks and rerank candidates. Qdrant supports dense/sparse hybrid workflows; PostgreSQL-based systems can combine vector search with full-text search. BM25 should not be assumed to be available automatically in every deployment or configuration.

Pillar 3: Metadata Filtering and Filter-Aware Search

Enterprise retrieval frequently restricts documents by tenant, authorization, region, freshness, or classification. These filters are both a correctness constraint and a performance input. In pgvector, SQL predicates interact with approximate scanning: tuning may involve HNSW iterative scans, search breadth, filtering indexes, partitioning, or partial ANN indexes. Qdrant can use payload indexes and filter-aware HNSW traversal, with indexing trade-offs under complex or selective filters. Neither engine guarantees a single-pass filtered search or immunity from post-filter latency. 

Pillar 4 : On-Disk Storage and Memory-Aware Indexing

Keeping indexes and frequently accessed vectors resident in memory can reduce lookup I/O, but replicating a large working set increases infrastructure cost. SSD-backed or memory-mapped designs reduce RAM pressure while making random-read performance and caching important. Qdrant exposes configurable placement of vector data and HNSW indexes, while PostgreSQL relies on its storage engine, operating-system cache, buffer management, and index maintenance. Neither necessarily requires every vector to reside in RAM. 

5. How to Scale Vector Search for Enterprise RAG Applications

Scaling begins with the retrieval experience users need, not an arbitrary database migration. Establish a baseline across representative questions and filters; then quantify the retrieval-quality and service-level targets that the platform must meet.

·         Profile real queries and define recall@k, p95/p99, throughput, availability, ingestion freshness, and cost targets.

·         Optimize the distance metric, candidate count, filtering, query plan, and index/search parameters before changing products.

·         Test quantization and, if applicable, reduced dimensions against answer quality rather than vector recall alone.

·         Isolate ingestion, indexing, and query bottlenecks using scheduling, replicas, or dedicated resources where supported.

·         Evaluate partitioning, sharding, replication, and placement only where measurements show benefit.

·         Continuously monitor latency percentiles, index health, memory residency, storage growth, and retrieval relevance; rerun tests after model or data changes.

Adding nodes cannot rescue ineffective chunking, incorrect authorization filters, or unsuitable index settings. Enterprise teams should validate the end-to-end RAG pipeline, including reranking, context assembly, and model response quality, before attributing every latency or relevance defect to the database.

6. Frequently Asked Questions

Should an enterprise use pgvector or switch to a dedicated vector database like Qdrant?

Prefer pgvector when PostgreSQL integration, transactional consistency, and existing operations outweigh specialized search functionality. Evaluate Qdrant when its quantization, filtering, hybrid search, or retrieval isolation capabilities address documented requirements. Run both on realistic data before committing.

What is the pgvector vs. Qdrant performance benchmark for 100 million vectors in 2026?

No single number represents a valid 2026 comparison. Dataset, embedding dimensions, distance metric, index configuration, hardware, concurrency, recall target, filter selectivity, ingestion load, and software version must be specified. Treat otherwise unmatched published results as illustrative rather than directly comparable.

How does scalar quantization affect vector search recall?

Eight-bit scalar quantization can reduce nominal component storage to one-quarter of FP32, but approximation may alter nearest-neighbor rankings. Benchmark recall on representative queries and assess any rescore strategy; no fixed recall percentage applies universally.

Can pgvector handle enterprise-scale RAG applications?

Yes, depending on vector dimensions, data distribution, indexes, filtering, concurrent load, hardware, and the required service-level objectives. There is no defensible universal collection-size threshold at which pgvector ceases to work.

When should an enterprise choose a dedicated vector database?

Choose a specialized engine when measured needs for filter-aware retrieval, quantization, hybrid queries, workload isolation, or distributed vector search outweigh the cost of another secured, monitored, backed-up, and integrated data service.

7. Build Scalable Vector Retrieval Architectures with NanoByte Technologies

Whether you need enterprise vector database architecture guidance, pgvector optimization services, or vector database scaling consulting, the starting point is an evidence-based assessment of the actual retrieval workload. A custom RAG database development company or experienced enterprise AI retrieval engineers can help evaluate index tuning, retrieval pipelines, hybrid search, quantization, and production integration.

For organizations planning to hire vector search engineers or hire senior Qdrant developers, a practical scope can include benchmark design, security and permissions review, measurable recall-latency targets, and deployment-cost modeling. NanoByte Technologies can be considered as a potential AI engineering partner to discuss these requirements; this article does not imply verified customer benchmark results or guarantee specific performance improvements.

Partner with NanoByte Technologies to evaluate your vector database architecture, identify retrieval bottlenecks, and develop a practical optimization roadmap for your enterprise RAG requirements.