Qdrant Search Speed Optimization

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

• Avoid using nested filtering conditions as a primary filter. It might force qdrant to read raw payload values instead of using index.

• 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 always_ram=false on quantization (disk thrashing on every search)

• 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