/search-speed-optimization

name: qdrant-search-speed-optimization
description: "Diagnoses and fixes slow Qdrant search. Use when someone reports 'search is slow', 'high latency', 'queries take too long', 'low QPS', 'throughput too low', 'filtered search is slow', or 'search was fast but now it's slow'. Also use when search performance degrades after config changes or data growth."

Diagnose a problem

There are 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:

• Read the slow request log (v1.16+, always on, per node) to find the slowest unique operations over 50 ms [Slow request log](https://skills.qdrant.tech/md/documentation/ops-monitoring/slow-request-log/)
• 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](https://skills.qdrant.tech/md/documentation/ops-optimization/optimize/?s=fine-tuning-search-parameters)
• Enable in-memory quantization: [Scalar quantization](https://skills.qdrant.tech/md/documentation/manage-data/quantization/?s=scalar-quantization)
• On v1.19+, store vectors as `datatype: turbo4` (4-bit, about 8x smaller) to cut disk reads. Lossy: the originals are no longer full precision, so check recall. Set it when creating the collection or adding a new named vector, so existing data must be re-ingested [turbo4](https://skills.qdrant.tech/md/documentation/manage-data/vectors/?s=turbo4)
• Reduce Vector Dimensionality with Matryoshka Models: [Matryoshka Models](https://skills.qdrant.tech/md/documentation/inference/matryoshka-models/?s=reduce-vector-dimensionality-with-matryoshka-models)
• Use oversampling + rescore for high-dimensional vectors [Search with quantization](https://skills.qdrant.tech/md/documentation/manage-data/quantization/?s=searching-with-quantization)
• Enable async I/O (`io_uring`) for disk-heavy workloads on Linux: `storage.performance.io_uring: auto` on Qdrant 1.19 or newer, `async_scorer: true` on 1.18 or older [Async I/O](https://skills.qdrant.tech/md/documentation/ops-configuration/memory-tiers/?s=async-io)

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](https://skills.qdrant.tech/md/documentation/ops-optimization/optimize/?s=maximizing-throughput)
• Use batch search API instead of single queries [Batch search](https://skills.qdrant.tech/md/documentation/search/search/?s=batch-search-api)
• Enable quantization to reduce CPU cost [Scalar quantization](https://skills.qdrant.tech/md/documentation/manage-data/quantization/?s=scalar-quantization)
• Add replicas to distribute read load [Replication](https://skills.qdrant.tech/md/documentation/scaling/distributed_deployment/?s=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](https://skills.qdrant.tech/md/documentation/manage-data/indexing/?s=payload-index)
• Use `is_tenant=true` for primary filtering condition: [Tenant index](https://skills.qdrant.tech/md/documentation/manage-data/indexing/?s=tenant-index)
• Try ACORN algorithm for complex filters: [ACORN](https://skills.qdrant.tech/md/documentation/search/search/?s=acorn-search-algorithm)
• `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](https://skills.qdrant.tech/md/documentation/manage-data/indexing/?s=per-element-index-for-arrays-of-objects).
• 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](https://skills.qdrant.tech/md/documentation/search/filtering/?s=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
• As an alternative to `indexed_only`, set `prevent_unoptimized: true` (v1.17.1+, experimental) to prevent searching over unindexed data. When it's on, set `wait=false` on all write requests, or writes block until indexing catches up.

Learn more in the [read-write contention guide](https://skills.qdrant.tech/md/documentation/ops-optimization/read-write-contention/)

What NOT to Do

• Set quantization to not stay