What is a segment in Qdrant's storage engine, and why does a collection consist of multiple segments rather than one monolithic index?

A segment is the smallest independently indexed unit in Qdrant's storage engine. It holds a set of points, and it owns its own vector storage, payload storage, payload indexes, and HNSW graph. A collection is a logical container composed of one or more segments, plus a write-ahead log and the optimizer state that governs how segments are created, merged, and vacuumed. When you search a collection, the request fans out to every segment, each segment returns its local top-k, and the results are merged into a global top-k. A segment is not a shard - a shard is a distributed unit that can contain many segments, and a segment lives entirely within one shard on one node.

The reason for multiple segments is that an HNSW graph is very expensive to mutate in place. Inserting a point into a large graph means wiring new edges and potentially rewiring existing ones, which is both slow and concurrency-hostile. The LSM-style solution Qdrant uses is to make existing segments immutable and append new points to a small, fresh segment. That new segment is immediately searchable without touching the large graph. Periodically the optimizer merges several small segments into a larger one, building a single consolidated HNSW graph and payload index in the process, then atomically replaces the sources. This gives three things at once: concurrent writes (new data goes to a small mutable segment while readers query the stable ones), background optimization (merging is off the critical write path), and bounded per-write cost (you never rewire the whole graph on an upsert). The cost is fan-out: searching N segments means N graph traversals plus a merge, and each segment has fixed overhead for its indexes and file handles. So there is a sweet spot for segment count - too few and merges are expensive and writes stall, too many and every query pays fan-out overhead.