What to Do When Qdrant Indexing Is Too Slow

What to Do When Qdrant Indexing Is Too Slow

Qdrant does NOT build HNSW indexes immediately. Small segments use brute-force until they exceed indexing_threshold_kb (default: 20 MB). Search during this window is slower by design, not a bug.

• Understand the indexing optimizer Indexing optimizer

Uploads/Ingestion Too Slow

Use when: upload or upsert API calls are slow. Identify bottleneck: client-side (network, batching) vs server-side (CPU, disk I/O)

For client-side, optimize batching and parallelism:

• Use batch upserts (64-256 points per request) Points API
• Use 2-4 parallel upload streams

For server-side, optimize Qdrant configuration and indexing strategy:

• Create more shards (3-12), each shard has an independent update worker Sharding
• Create payload indexes before HNSW builds (needed for filterable vector index) Payload index

Suitable for initial bulk load of large datasets:

• Disable HNSW during bulk load (set indexing_threshold_kb very high, restore after) Collection params
• Setting m=0 to disable HNSW is legacy, use high indexing_threshold_kb instead

Careful, fast unindexed upload might temporarily use more RAM and degrade search performance until optimizer catches up.

See https://search.qdrant.tech/md/documentation/tutorials-develop/bulk-upload/

Optimizer Stuck or Taking Too Long

Use when: optimizer running for hours, not finishing.

• Check actual progress via optimizations endpoint (v1.17+) Optimization monitoring
• Large merges and HNSW rebuilds legitimately take hours on big datasets
• Check CPU and disk I/O (HNSW is CPU-bound, merging is I/O-bound, HDD is not viable)
• If optimizer_status shows an error, check logs for disk full or corrupted segments