Questions
11 of 18
1Why did Qdrant consolidate search, recommend, and discovery operations into the Universal Query API?
2What is a prefetch stage in Qdrant's Universal Query API, and why would you use multiple prefetches?
3How do Reciprocal Rank Fusion and Distribution-Based Score Fusion differ when combining Qdrant prefetch results?
4How would you retrieve 500 candidates with dense vectors and rerank them using a ColBERT multivector?
5What is Qdrant's recommend query mode, and how is it different from plain similarity search?
6How does Qdrant combine vector similarity search with structured payload filters?
7What are must, should, and must_not clauses in a Qdrant payload filter?
8Why can filtering after an ANN search return too few results when the filter is highly selective?
9How does Qdrant's filtered vector search avoid the classic post-filtering problem?
10How would you implement a geo-radius search for similar items within 5 km of a location in Qdrant?
11Why should you create payload indexes for fields that are filtered frequently at scale?
12What payload index types does Qdrant support, and how would you choose one for tags versus price?
13What is a full-text payload index used for, and how does it differ from an exact-match keyword index?
14What is the cost of creating too many payload indexes on a high-write Qdrant collection?
15Why should point uploads be batched instead of sending one upsert request per point?
16What is Qdrant's Scroll API used for, and why is it preferable to vector search when iterating through matching points?
17How does Qdrant Scroll pagination avoid the main performance problem of large SQL OFFSET pagination?
18What is a realistic batch size for bulk-loading millions of Qdrant points, and what factors should influence it?
11 / 18

Why should you create payload indexes for fields that are filtered frequently at scale?

Payload indexes accelerate structured filtering

A payload index gives Qdrant an index structure for a field so it can evaluate filter conditions without repeatedly scanning all candidate payload values. As the collection grows, that can make the difference between predictable filtered retrieval and increasingly expensive candidate evaluation.

The reason Qdrant does not simply index every payload field automatically is that indexes consume memory and storage and add maintenance work on writes. The useful index set depends on actual query patterns and field types.

The trade-off is read performance versus write and resource overhead. For a high-cardinality field used on nearly every query, an index can be valuable. For a field that is rarely filtered, the additional index may not justify its cost.

A common misconception is that any filter becomes fast merely because it is syntactically present in a query. At scale, you should inspect the payload index configuration and benchmark the actual filter workload. Exact planner behavior can change across Qdrant releases.

javascript
  1. 1

    Payload indexes accelerate repeated structured filtering

  2. 2

    Indexes consume resources and add write maintenance

  3. 3

    Index only fields that materially benefit production query patterns

  4. 4

    Index type should match the payload field and query semantics

Difficulty: 5/10
Topics: Payload indexing, Filtering, Performance

Scenario Questions

0-2 years experience
  1. 1

    A category filter works on 1,000 points but becomes slow on 10 million points. What database feature would you investigate?

  2. 2

    Why not create indexes on every payload field just in case a future query needs them?

2-5 years experience
  1. 1

    A tenant_id filter appears on almost every production query. What evidence would justify creating a payload index for it?

  2. 2

    Adding several payload indexes improves reads but reduces ingestion throughput. How would you identify whether the indexes are worth keeping?

5-8 years experience
  1. 1

    Your collection has hundreds of payload fields but only ten appear in filters. How would you establish an indexing policy?

  2. 2

    A high-cardinality filter has excellent selectivity but its index consumes substantial memory. How would you evaluate that trade-off?

8+ years experience
  1. 1

    You operate Qdrant for workloads with unpredictable filter patterns. How would you balance automatic index creation against resource governance?

  2. 2

    A write-heavy workload has strict ingestion SLOs while search teams want many payload indexes. How would you create an organization-wide policy for this conflict?

Follow-up Questions

  • Which payload fields are good candidates for indexing?
  • What costs do payload indexes add to writes?