Qdrant

Qdrant is a purpose-built vector database written in Rust, sitting deliberately between two extremes: richer than “a vector column in Postgres” and far lighter to operate than a disaggregated platform like Milvus. One binary, one collection model, one job: store embeddings with their metadata and return the nearest neighbours, fast, with filters applied during the search rather than after it.

The data model

• Collection: the table equivalent; fixes the vector dimension and distance metric (cosine, dot, or euclidean) at creation.
• Point: one record - an id, one or more vectors, and an arbitrary JSON payload.
• Named vectors: a point can carry several vectors (dense, sparse, colbert) in one schema, so hybrid retrieval lives in a single point instead of across stores.

The payload is the differentiator in practice: filter clauses on payload fields are evaluated during graph traversal, not as a post-filter on results - so “nearest neighbours among tenant_id=42 AND year>2024” stays fast instead of silently degrading.

Indexing: HNSW plus quantisation

The workhorse index is HNSW - a graph index giving high recall at interactive latency. Qdrant layers quantisation on top for memory pressure:

• Scalar quantisation (int8): 4x smaller vectors, small recall cost.
• Product quantisation: more compression, more recall cost.
• Binary quantisation: extreme compression, pairs well with a rescore pass.

The standard pattern is quantised vectors for the candidate search plus the original vectors for rescoring - memory drops several-fold while effective recall stays near the unquantised index. Vectors can also be kept on disk (on_disk: true) with mmap, trading latency for capacity.

Consistency and replication

There are no multi-point ACID transactions; per-point writes are atomic. In cluster mode (since 1.x), Qdrant shards collections across nodes and replicates shards with Raft consensus - shard leaders fail over automatically, and the collection keeps serving during node loss. Consistency read-your-writes concerns are small because writes commit through Raft before ack.

Scaling

• Vertical: HNSW is memory-hungry; size RAM against your vector count times bytes-per-vector after quantisation.
• Horizontal: cluster mode shards collections; replication factor per shard gives both read scaling and failover.
• Disk-bound: on_disk vectors plus quantisation let very large collections run on modest RAM at somewhat higher latency.

Operations

One binary or one container - a real operational difference from Milvus. State lives in the data directory; snapshots give portable backups. Cluster mode needs an odd number of nodes for Raft. The honest watch items: memory pressure against HNSW, segment merge/compaction I/O, and shard rebalance after adding nodes.

What actually breaks

• Unquantised HNSW at scale: memory fills, the kernel OOM-kills the node. Quantise or go on_disk before the cliff, not after.
• Filter cardinality surprise: a payload filter matching a tiny fraction of points can slow traversal; a payload index on the filtered fields is the fix.
• Recreate-to-change-metric: distance metric is fixed at collection creation; changing it is a re-ingest, not an ALTER.
• Expecting transactional semantics across points - batch operations are not atomic across points; handle partial failure at the client.

Where Qdrant is the wrong choice

Under ~a few hundred thousand vectors with the metadata already in Postgres, pgvector inside your existing database is simpler: one system, transactions, joins to the business data. At genuine billion-vector scale or as a shared multi-team vector platform, Milvus is the heavyweight answer. Qdrant is the sweet spot when you want dedicated vector search that one engineer can actually run.