Vector Database Performance: Benchmarking pgvector, Qdrant, and Milvus for Production RAG

By /

Retrieval-Augmented Generation (RAG) systems live or die on the performance of their vector retrieval layer. As RAG moves from prototype to production, the choice of vector database becomes a first-order engineering decision affecting query latency at scale, memory footprint, recall accuracy, and operational complexity. This benchmark examines three leading options — pgvector, Qdrant, and Milvus — across the dimensions that matter most for production RAG deployments.

Test Environment and Methodology

All benchmarks were performed on a single c6i.4xlarge instance (16 vCPU, 32 GB RAM) running Linux, with a 1-million vector dataset generated from a representative enterprise document corpus. Vectors are 1536-dimensional (OpenAI text-embedding-3-small output). Each database was configured with its recommended production settings. Tests were repeated 10 times with results averaged; the first run was discarded as a warm-up.

Benchmark dimensions:

  • Insert throughput: Batch insertions of 1M vectors (batches of 1,000)
  • Query latency: P50, P95, P99 at 10 QPS, 50 QPS, and 100 QPS concurrency
  • Recall accuracy: Percentage of true top-10 nearest neighbors returned (measured against brute-force ground truth)
  • Memory footprint: RSS after full dataset load with index built
  • Index build time: Time to build HNSW index over 1M vectors

pgvector

pgvector is a PostgreSQL extension that adds vector storage and similarity search operations. It integrates directly into PostgreSQL, making it the natural choice for teams already running Postgres.

Insert Throughput

pgvector inserts are standard PostgreSQL writes — ACID-compliant and synchronous. This provides durability guarantees that purpose-built vector databases sacrifice for speed. Bulk insertion throughput: approximately 18,000 vectors/second using COPY for batch ingestion.

Query Latency

At 10 QPS with HNSW index (ef_search=64, m=16):

P50:  8ms
P95: 22ms
P99: 41ms

At 100 QPS (100 concurrent goroutines, connection pool of 32):

P50:  34ms
P95: 112ms
P99: 287ms

Performance degrades notably under high concurrency due to PostgreSQL’s process-per-connection model and lock contention on the HNSW index structure during concurrent reads.

Recall Accuracy

At ef_search=64: 0.95 recall. At ef_search=128: 0.98 recall. The HNSW implementation in pgvector is correct and matches theoretical expectations for the algorithm.

Memory Footprint

1M vectors at 1536 dimensions: approximately 6.5 GB RSS. PostgreSQL’s shared_buffers and effective_cache_size settings significantly affect performance — under-provisioning RAM causes index pages to be evicted, dramatically increasing latency.

Strengths

  • No additional infrastructure — uses your existing Postgres
  • Full SQL capabilities: hybrid queries that combine vector search with structured filters are natural SQL JOINs
  • ACID transactions: vector upserts are atomic with metadata updates
  • Mature operational tooling: pgBackRest, Patroni, PgBouncer all work unchanged
  • Excellent for corpora under 5M vectors with moderate QPS requirements

Qdrant

Qdrant is a purpose-built vector database written in Rust, optimized for high-throughput similarity search with rich filtering capabilities. It is designed as a standalone service with its own API.

Insert Throughput

Qdrant’s gRPC batch insertion API achieves approximately 85,000 vectors/second for 1536-dimensional vectors with payload indexing. Asynchronous ingestion mode (optimizers running in background) allows insertion rates to exceed the indexing rate temporarily, with indexing catching up in the background.

Query Latency

At 10 QPS with HNSW (ef=128, m=16):

P50:  2ms
P95:  5ms
P99:  9ms

At 100 QPS:

P50:  4ms
P95: 12ms
P99: 28ms

Qdrant maintains low tail latency under concurrent load due to its multi-threaded Rust architecture and lock-free read paths.

Recall Accuracy

At ef=128: 0.98 recall. Qdrant’s filtered search (combining vector similarity with payload field conditions) maintains recall accuracy — some vector databases degrade significantly when filters are applied, requiring a larger ef to compensate.

Memory Footprint

1M vectors: approximately 5.1 GB RSS with vectors loaded into RAM. Qdrant supports on-disk storage for vectors with mmap, reducing RAM requirements at a 3-5x latency cost — useful for large corpora where full in-memory operation is cost-prohibitive.

Strengths

  • Best query latency of the three, especially under concurrent load
  • Excellent filtered vector search performance
  • Built-in payload indexing for structured metadata filtering
  • Snapshots and collection aliasing for zero-downtime reindex operations
  • REST and gRPC APIs with official client libraries for Python, Rust, Go, TypeScript

Milvus

Milvus is an open-source vector database designed for massive scale, originally developed at Zilliz. It supports multiple index types, horizontal scaling via distributed architecture, and is the most operationally complex of the three options.

Insert Throughput

Milvus uses a streaming write path (Kafka or Pulsar) that buffers writes before flushing to object storage. Effective insertion throughput: approximately 120,000 vectors/second in a single-node deployment. In a distributed configuration, throughput scales horizontally with the number of query nodes.

Query Latency

At 10 QPS (HNSW index, ef=128):

P50:  5ms
P95: 14ms
P99: 28ms

At 100 QPS:

P50:  9ms
P95: 32ms
P99: 71ms

Milvus latency is higher than Qdrant in single-node configuration due to internal coordination overhead. The distributed architecture amortizes this across nodes at scale.

Recall Accuracy

At ef=128 with IVF_HNSW index: 0.97 recall. Milvus supports more index types than the others (IVF_FLAT, IVF_SQ8, IVF_PQ, HNSW, ANNOY, DiskANN) allowing you to trade recall for speed or memory more granularly.

Memory Footprint

1M vectors in single-node mode: approximately 7.2 GB RSS. Milvus also requires etcd (metadata), MinIO or S3 (object storage for segments), and optionally Kafka/Pulsar for the write-ahead log — the full dependency stack requires significantly more total memory than Qdrant or pgvector.

Strengths

  • Designed for 100M+ vector scale horizontal distribution
  • Widest index type selection for different recall/latency tradeoffs
  • Multi-tenancy via collections and partitions
  • Mature Kubernetes operator (Milvus Operator) for production deployment

Comparison Summary

Metric                    pgvector      Qdrant        Milvus
-----------------------------------------------------------------
Insert throughput         18K/s         85K/s         120K/s
Query P50 (10 QPS)        8ms           2ms           5ms
Query P99 (100 QPS)       287ms         28ms          71ms
Recall (ef=128)           0.98          0.98          0.97
Memory (1M 1536-dim)      6.5 GB        5.1 GB        7.2 GB (+deps)
Index build (1M vecs)     18 min        4 min         7 min
Operational complexity    Low           Medium        High
Existing Postgres reuse   Yes           No            No

Choosing for Production RAG

The decision depends on your scale, operational context, and existing infrastructure:

  • Choose pgvector if you already run PostgreSQL, your corpus is under 5M vectors, and your QPS requirements are modest (under 50 concurrent queries). The operational simplicity is worth the performance concessions.
  • Choose Qdrant if you need the best query latency, your filtering requirements are complex, and your corpus is between 1M and 50M vectors. It is the best balanced option for most production RAG systems.
  • Choose Milvus if you need to scale beyond 100M vectors, require horizontal write scaling, or have specific index type requirements. Accept the operational overhead as the cost of that scale.

Operational Considerations

Beyond raw performance, the operational reality of running each system in production matters. pgvector benefits from PostgreSQL’s ecosystem: mature backup tools, logical replication for read replicas, and operational familiarity on most engineering teams. Qdrant’s snapshot API makes collection backup and migration straightforward, and it runs as a single stateless binary (or distributed with Raft consensus). Milvus requires operating etcd, object storage, and optionally a message queue — plan for these dependencies in your infrastructure budget and on-call burden.

Conclusion

For most organizations building production RAG systems today, Qdrant represents the best balance of query performance, operational simplicity, and scalability headroom. pgvector is the right pragmatic choice for teams already invested in PostgreSQL who cannot justify the operational overhead of a dedicated vector service. Milvus is the choice when scale requirements are genuinely in the hundreds of millions of vectors or when the sophisticated index type selection provides a meaningful advantage for your specific workload. Benchmark all three against your actual data and query patterns before committing — synthetic benchmarks are directionally useful but no substitute for testing on your own corpus.

Scroll to Top