Vector Databases in Production: Comparing Qdrant, Milvus, Weaviate, and pgvector Architecture, Indexing Overhead, Filtered Search, and Serving Economics

Deploying vector search in production requires navigating fundamental trade-offs across storage topology, indexing latency, memory allocation, and metadata filtering overhead. As retrieval-augmented generation (RAG), multimodal search, and agentic memory architectures scale beyond tens of millions of embeddings, database selection determines whether inference latency remains bounded or collapses under complex filtering constraints.

The current vector infrastructure ecosystem divides into two primary paradigms: dedicated vector engines optimized for high-dimensional approximate nearest neighbor (ANN) graph traversal and relational database extensions designed to co-locate vector embeddings with transactional operational data. Evaluating Qdrant, Milvus, Weaviate, and pgvector reveals significant architectural divergences in how each engine manages graph indexes, handles metadata predicates, executes vector quantization, and scales horizontally.

Engine Architecture and Storage Topologies

Vector engines approach the data lifecycle through distinct architectural philosophies, ranging from embedded systems to fully disaggregated cloud-native microservices.

Qdrant: Payload-Centric In-Memory and Mmap Engine

Qdrant is implemented in Rust and follows a monolithic, service-oriented architecture where compute, indexing, and storage live within single-node processes or Raft-coordinated distributed clusters. Data is organized into collections subdivided into segments. Each segment contains its own vector index, payload store, and inverted metadata index.

Qdrant utilizes memory-mapped (mmap) files for vector storage, allowing operating systems to page vector vectors in and out of RAM dynamically. Payloads (metadata) are stored in an embedded key-value store (RocksDB or custom chunked payload storage), enabling arbitrary JSON payload structures to be directly bound to vector IDs without separate schema registration.

Milvus: Disaggregated Cloud-Native Microservices

Milvus is engineered in Go and C++ around a fully decoupled, cloud-native storage-and-compute architecture. It disaggregates the database lifecycle into stateless coordinator nodes (RootCoord, QueryCoord, DataCoord, IndexCoord), stateless worker nodes (QueryNodes, DataNodes, IndexNodes), a shared write-ahead log (Pulsar or Kafka), metadata storage (etcd), and object storage (MinIO, Amazon S3, or Google Cloud Storage).

The vector execution engine in Milvus is Knowhere, a dedicated C++ acceleration layer integrating multiple ANN algorithms including HNSW, DiskANN, and GPU-accelerated IVF-PQ. Writes enter a message broker and are persisted into immutable columnar data segments stored directly in cloud object storage, making Milvus capable of scaling storage and compute independently at massive billion-vector scale.

Weaviate: Graph-Native Schema with Modular Storage

Weaviate is written in Go, with C/C++ SIMD-optimized vector math kernels. It employs an object-centric, graph-like schema where data entities contain properties, vector representations, and cross-references.

Under the hood, Weaviate uses custom Log-Structured Merge-tree (LSM) key-value stores for property storage and Roaring Bitmaps for inverted index metadata filtering. Its modular plugin architecture allows vectorizer modules (such as Hugging Face, Cohere, or OpenAI transformers) to be run inline within the database process, transforming incoming text into embeddings automatically before storage.

pgvector: Relational Extension on PostgreSQL ACID Foundations

pgvector is a C-based extension for PostgreSQL that introduces native vector data types (vector, halfvec, sparsevec) directly into the relational engine. Unlike dedicated vector databases, pgvector relies entirely on PostgreSQL internals: the shared memory buffer pool (shared_buffers), write-ahead logging (WAL), Multi-Version Concurrency Control (MVCC), and the PostgreSQL cost-based query planner.

Vectors in pgvector are stored as standard table attributes, subject to PostgreSQL tuple storage and TOAST (The Oversized-Attribute Storage Technique) mechanics. Queries are expressed through standard SQL using distance operators (<-> for Euclidean, <=> for Cosine, <#> for Negative Inner Product), allowing vector similarity searches to be joined directly with relational tables in a single transactional query.

Indexing Strategies and Computational Overhead

High-dimensional vector search requires balancing indexing build time, graph update costs, and query recall.

Graph Indexes: HNSW Parameterization

Hierarchical Navigable Small World (HNSW) graphs remain the standard ANN index across all four systems, but their memory footprints and update dynamics vary widely.

Qdrant: Builds multi-layer HNSW graphs per segment. Dynamic segment merging allows background threads to consolidate small segments into optimized large graphs without locking read operations.
Milvus: Executes HNSW construction inside dedicated IndexNodes. Index creation is batch-driven and offloaded from the query path, preventing ingestion spikes from degrading search latency.
Weaviate: Builds dynamic HNSW graphs per class shard. Supports concurrent insertion and search, but high ingestion concurrency increases garbage collection overhead and memory fragmentation in the Go runtime.
pgvector: Implements HNSW indexing directly within PostgreSQL maintenance workers. Building an HNSW index requires setting maintenance_work_mem sufficiently high to prevent disk swapping. Graph construction is CPU and memory intensive; unoptimized builds on millions of vectors can saturate write workers.

Quantization and Compression Mechanisms

Raw floating-point vectors (FP32 or FP16) require significant memory. Storing 10 million 1536-dimensional FP32 vectors consumes approximately 61.4 GB of RAM solely for the raw embeddings, excluding graph overhead.

Scalar Quantization (SQ): Compresses FP32 vectors to INT8 (1 byte per dimension), reducing memory consumption by 4x with minimal recall loss (typically under 1%). Qdrant, Milvus, and Weaviate provide native SQ with automatic threshold calibration.
Product Quantization (PQ): Decomposes vector space into sub-vectors and clusters them into centroids, reducing memory by 8x to 16x at the cost of indexing build time and slight recall degradation.
Binary Quantization (BQ): Compresses dimensions to 1 bit (using 1 bit per float based on sign), achieving a 32x memory reduction and ultra-fast Hamming distance computation via SIMD instructions. Qdrant and Weaviate support BQ with full-precision rescoring over top candidates.
Half-Precision (FP16 / halfvec): Supported natively in pgvector via the halfvec type, cutting memory and storage requirements by 50% relative to standard FP32 vectors without algorithmic loss.

Filtered Search Execution Models

Metadata filtering is the primary failure mode of naive vector search implementations. When queries combine similarity thresholds with categorical or temporal filters (such as tenant IDs, access control lists, or date ranges), engines execute filtering across three distinct paradigms.

1. Post-Filtering (Scan and Discard)

In post-filtering, the database retrieves the top-K nearest neighbors from the vector index and subsequently applies metadata predicates. If a filter matches only 1% of the dataset, a top-10 ANN search will almost certainly return zero valid results, collapsing search recall.

2. Pre-Filtering (Iterative Scan / Candidate Filtering)

Pre-filtering identifies all matching document IDs via an inverted index before searching vectors. However, if the candidate list is large, searching an unindexed subset naively requires a brute-force sequential scan.

Qdrant (Custom Filtered HNSW): Qdrant integrates metadata filtering directly into the HNSW graph traversal. During graph navigation, neighbor exploration evaluates payload conditions in real time. If the filter is restrictive, Qdrant switches automatically to payload index traversal; if the filter is relaxed, it navigates the HNSW graph while skipping non-matching nodes without breaking graph connectivity.
Milvus (Bitset Masking with Knowhere): Milvus executes scalar filtering on DataNodes/QueryNodes to generate a bitset mask. Knowhere passes this bitset into SIMD-accelerated HNSW or IVF kernels, masking out invalid vector IDs during distance calculations.
Weaviate (Roaring Bitmaps): Weaviate maintains inverted indexes using Roaring Bitmaps. Filter queries perform bitmap intersection and union operations to produce an allowed ID set, which is passed to the HNSW traversal layer to restrict graph exploration.
pgvector (Iterative Index Scans): In pgvector versions prior to 0.8.0, filtered queries frequently suffered from recall collapse because filtering occurred after HNSW candidate retrieval (hnsw.ef_search). Starting with pgvector 0.8.0, iterative index scans (SET hnsw.iterative_scan = relaxed or strict) allow PostgreSQL to dynamically advance the HNSW graph scan until LIMIT matching rows are satisfied or hnsw.max_scan_tuples is reached. Alternatively, engineers use partial indexes (CREATE INDEX ... WHERE tenant_id = 'X') for highly selective partitions.

Production Serving Economics and Operational Profiles

Selecting an engine involves balancing operational complexity against infrastructure cost per queries per second (QPS).

Memory and Disk Footprint

Qdrant: Low to moderate memory overhead. Excellent memory efficiency when pairing on-disk payload storage with scalar-quantized vectors in RAM.
Milvus: High baseline infrastructure footprint due to etcd, Pulsar/Kafka, and MinIO dependencies. However, it achieves the lowest marginal cost at ultra-large scale (>100M vectors) due to DiskANN and tiered object storage offloading.
Weaviate: Moderate to high memory footprint. Go garbage collection dynamics require provisioning 1.5x to 2x the calculated vector memory to prevent out-of-memory (OOM) crashes during heavy ingestion spikes.
pgvector: Highly resource-efficient for existing PostgreSQL workloads. Vectors share buffer memory with relational data. However, large HNSW graphs must fit entirely within shared_buffers / OS file cache to avoid severe disk I/O bottlenecks during concurrent query execution.

Operational Complexity and Maintenance

pgvector: Lowest operational friction for teams already running PostgreSQL. Zero new infrastructure components, native backup tools (pg_dump, WAL-G), and full ACID transactional consistency.
Qdrant: Low to moderate operational complexity. Single binary deployment, native Raft clustering, clean REST and gRPC interfaces, and integrated snapshot APIs.
Weaviate: Moderate operational complexity. Straightforward container deployment for single-node setups; distributed multi-node clustering requires careful shard configuration and memory tuning.
Milvus: Highest operational complexity. Managing a distributed Milvus cluster in production requires Kubernetes orchestration, persistent volume provisioning, message broker tuning, and dedicated platform engineering oversight.

Architectural Selection Matrix

Engine selection should align with dataset scale, filtering selectivity, and existing team infrastructure:

Choose pgvector when total vector volume is under 10 million embeddings, metadata predicates require complex relational joins or strict ACID transactional integrity, and the engineering team prioritizes operational simplicity within existing PostgreSQL infrastructure.
Choose Qdrant when dataset size ranges from 1 million to 100 million embeddings, high-throughput filtered search with low tail latency (P99 < 15ms) is critical, and the team prefers a lightweight, resource-efficient standalone vector engine.
Choose Weaviate when applications require native hybrid search (BM25 keyword search combined with dense vector similarity via Reciprocal Rank Fusion), built-in multi-tenancy isolation across thousands of discrete customer namespaces, or embedded vectorization pipelines.
Choose Milvus when scaling to hundreds of millions or billions of vectors, where independent horizontal scaling of ingestion, indexing, and querying is mandatory, and the organization possesses dedicated Kubernetes infrastructure capabilities.