Qdrant organizes data around a small set of core abstractions. Click any card below to reveal the real-world analogy and why each concept matters.
Collections
Named containers that hold points with shared configuration -- vector size, distance metric, HNSW parameters, and quantization settings.
Analogy: A filing cabinet drawer with a specific label. The drawer has fixed dimensions (vector size), a sorting method (distance metric), and organizational rules (indexing parameters). One drawer for "product embeddings," another for "user profiles."
Why it matters: Collections are the unit of configuration, sharding, and replication. The parameters you choose at creation time -- m, ef_construct, quantization -- determine the performance profile of every search against that data.
Points
The fundamental data records: a unique ID, one or more vectors, and an optional JSON payload of metadata.
Analogy: A library catalog card with a catalog number (ID), a location code showing where the book sits on the shelves (vector position in embedding space), and descriptive info like title, author, genre (payload).
Why it matters: Points are the atomic unit of storage and search. Every upsert, delete, search hit, and filter evaluation operates on points. Vectors and payloads are stored separately -- vectors in optimized formats for fast distance computation, payloads indexed for efficient filtering.
Vectors
Fixed-length arrays of floats encoding semantic meaning. Qdrant supports dense, sparse, and multi-vectors with multiple distance metrics.
Analogy: GPS coordinates, but in hundreds of dimensions. Just as GPS encodes physical location so you can find nearby places, embedding vectors encode semantic meaning so you can find similar concepts. Two reviews with similar sentiment have vectors that are "close together."
Why it matters: Vector quality determines search quality. Qdrant supports Cosine, Euclidean, Dot Product, and Manhattan distance. Named vectors let a single point be searchable from multiple perspectives (text embedding + image embedding).
Payloads
JSON metadata attached to points -- strings, numbers, booleans, arrays, geo-coordinates, datetimes. Indexed fields enable filtered search.
Analogy: If vectors are GPS coordinates of a restaurant, payloads are the Yelp listing: cuisine type, price range, hours, ratings. The vector finds semantically similar places; payload filters narrow results to "Italian, under $30, open now."
Why it matters: Real-world search combines similarity with structured filtering. Qdrant integrates filtering directly into HNSW graph traversal rather than post-processing, preserving quality even with highly selective filters.
HNSW Index
The graph-based approximate nearest neighbor algorithm powering Qdrant's search. Multi-layer graph traversed in O(log N) time.
Analogy: Finding a coffee shop in a city using a social network. At the top level, a well-connected friend points you to the right neighborhood. Next level, a local points you to the right block. Bottom level, someone knows every shop. Each level narrows search -- you visit a handful of nodes out of millions.
Why it matters: HNSW makes Qdrant fast. Key parameters: m (connections per node -- more = better recall, more memory), ef_construct (build quality), hnsw_ef (query-time recall vs. latency). Qdrant extends HNSW with filter-aware graph construction.
Segments
Internal storage partitions within a collection, each with its own vectors, payloads, indexes, and ID mappings. Managed by the optimizer.
Analogy: Chapters in a book being written. New data goes into the current "draft" chapter (appendable, unindexed). The optimizer periodically "publishes" chapters by building HNSW indexes (non-appendable, optimized). Old chapters get merged. The reader searches all chapters in parallel.
Why it matters: Segments enable concurrent reads and writes without blocking. Writes go to appendable segments while searches hit indexed ones. The optimizer runs in background, building indexes and applying quantization without interrupting queries.
How They Fit Together
When you upsertInsert a new point or update an existing one. Qdrant uses "upsert" (update + insert) semantics -- if the ID exists, the point is replaced. a point into Qdrant, it is written to the WALWrite-Ahead Log -- a durability mechanism that records operations before applying them. On crash, uncommitted WAL entries are replayed to recover state. of the local shard, then inserted into the current appendable segment. The payload indexStructPayloadIndex -- an index structure built on payload fields (keyword, numeric, geo, etc.) that enables fast filtered search without scanning all payloads. updates to include the new point.
In the background, the optimizerA background process that builds HNSW indexes on accumulated data, merges small segments, applies quantization, and vacuums deleted points -- all without blocking searches. monitors segment sizes and triggers merges: combining small segments, building HNSW graphs, and applying quantizationVector compression that reduces memory footprint. Scalar (int8) gives 4x reduction; binary gives 32x but only works with compatible models.. When you search, the query planner selects the optimal strategy per segment based on filter selectivity, results from all segments and shards are merged, and the top-k results are returned.