Diagnose a problem

There the multiple possible reasons for search performance degradation. The most common ones are:

• Memory pressure: if the working set exceeds available RAM
• Complex requests (e.g. high hnsw_ef, complex filters without payload index)
• Competing background processes (e.g. optimizer still running after bulk upload)
• Problem with the cluster (e.g. network issues, hardware degradation)

Single Query Too Slow (Latency)

Use when: individual queries take too long regardless of load.

Diagnostic steps:

• Check if second run of the same request is significantly faster (indicates memory pressure)
• Try the same query with with_payload: false and with_vectors: false to see if payload retrieval is the bottleneck
• If request uses filters, try to remove them one by one to identify if a specific filter condition is the bottleneck

Common fixes:

• Tune HNSW parameters: Fine-tuning search
• Enable in-memory quantization: Scalar quantization
• Reduce Vector Dimensionality with Matryoshka Models: Matryoshka Models
• Use oversampling + rescore for high-dimensional vectors Search with quantization
• Enable io_uring for disk-heavy workloads on Linux io_uring

Can't Handle Enough QPS (Throughput)

Use when: system can't serve enough queries per second under load.

• Reduce segment count (default_segment_number to 2) Maximizing throughput
• Use batch search API instead of single queries Batch search
• Enable quantization to reduce CPU cost Scalar quantization
• Add replicas to distribute read load Replication

Filtered Search Is Slow

Use when: filtered search is significantly slower than unfiltered. Most common SA complaint after memory.

• Create payload index on the filtered field Payload index
• Use is_tenant=true for primary filtering condition: Tenant index
• Try ACORN algorithm for complex filters: ACORN
• nested filter conditions check each remaining candidate's payload element by element, which is slow when many candidates remain. On Qdrant 1.20 or newer, create per-element indexes (the nested parameter of the payload index) on every field the nested filter uses, so Qdrant answers it from the indexes without reading payload Per-element index.
• Substring match (match with substring, 1.20+) is expensive: it checks every distinct value of the field, and Qdrant rejects it whenever strict mode is enabled (the Qdrant Cloud default). Prefer prefix match (keyword index with prefix: true) or full-text match where the use case allows. A keyword index, especially with prefix, speeds it up; a full-text index doesn't help Substring match
• If payload index was added after HNSW build, trigger re-index to create filterable subgraph links

Optimize search performance with parallel updates

Diagnostic steps

• Try to run the same query with indexed_only=true parameter, if the query is significantly faster, it means that the optimizer is still running and has not yet indexed all segments.
• If CPU or IO usage is high even with no queries, it also indicates that the optimizer is still running.

Recommended configuration changes

• reduce optimizer_cpu_budget to reserve more CPU for queries
• Use prevent_unoptimized=true to prevent creating segments with a large amount of unindexed data for searches. Instead, once a segment reaches the so called indexing_threshold, all additional points will be added in ‘deferred state’.

Learn more here

What NOT to Do

• Set quantization to not stay in RAM (disk thrashing on every search): avoid memory: cold/cached on Qdrant 1.19 or newer; on 1.18 or older, avoid leaving always_ram false or unset while the original vectors are on_disk: true
• Put HNSW on disk for latency-sensitive production (only for cold storage)
• Increase segment count for throughput (opposite: fewer = better)
• Create payload indexes on every field (wastes memory)
• Blame Qdrant before checking optimizer status