Collection, point, vector and payload
At the top level, a collection is a named group of points that share a vector configuration. A point is the individual record Qdrant searches and consists of an ID, one or more vectors, and optional payload.
Vectors are the numerical representations used for similarity search, while payload is structured JSON metadata attached to the point. In practice, the useful mental model is Collection -> Point -> vectors plus payload, with the collection defining how each vector space is indexed and compared.
This model is intentionally different from a relational schema. You do not normally create a row with arbitrary vector dimensions and then use a SQL-style index; instead, you define the vector configuration at the collection/vector-space level and store records as points.
A common mistake is treating a collection as just a table name. Its vector configuration is part of the search contract. With named vectors, one point can hold multiple vector spaces, each with its own dimensionality and distance configuration.
A collection groups points and defines vector-space configuration
A point has an ID, vector data, and optional payload
Payload carries structured metadata used for filtering and response enrichment
Named vectors allow multiple vector spaces on one point
You need to store product descriptions with category and price metadata. Where would you put each piece of information in Qdrant?
A developer creates one collection per document. What problems could that data model create?
Your points need both text and image embeddings. How would you model them if searches can target either modality?
You need to change the embedding dimension of an existing vector space. What migration approach would you use?
A collection contains millions of points and you need to introduce a second embedding model without disrupting existing search traffic. How would you evolve the collection schema?
Different teams want incompatible vector configurations but insist on sharing one collection. How would you determine whether named vectors solve the requirement?
You are designing a multi-tenant platform with multiple modalities and model versions. How would you structure collections and named vectors to balance isolation, operational overhead, and migration safety?
A platform team proposes one enormous collection for every business domain. What architectural risks would you evaluate before approving it?