What are the three core building blocks of Qdrant's data model?
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.
- 1
A collection groups points and defines vector-space configuration
- 2
A point has an ID, vector data, and optional payload
- 3
Payload carries structured metadata used for filtering and response enrichment
- 4
Named vectors allow multiple vector spaces on one point
Scenario Questions
0-2 years experience
- 1You need to store product descriptions with category and price metadata. Where would you put each piece of information in Qdrant?
- 2A developer creates one collection per document. What problems could that data model create?
2-5 years experience
- 1Your points need both text and image embeddings. How would you model them if searches can target either modality?
- 2You need to change the embedding dimension of an existing vector space. What migration approach would you use?
5-8 years experience
- 1A 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?
- 2Different teams want incompatible vector configurations but insist on sharing one collection. How would you determine whether named vectors solve the requirement?
8+ years experience
- 1You 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?
- 2A platform team proposes one enormous collection for every business domain. What architectural risks would you evaluate before approving it?
Follow-up Questions
- Why would you use named vectors instead of separate collections?
- What configuration is fixed at collection creation for a dense vector space?