Why does Qdrant recommend disabling indexing (or raising the indexing threshold) during a large bulk import, then re-enabling it afterward?

Building an HNSW graph incrementally is far more expensive per point than building it once over a batch. Each incremental insert has to run a graph search to find the insertion neighborhood, apply the diversity heuristic, wire new edges, and potentially rewire the neighbors' edges if they exceed m. That work is done point by point, with poor locality and repeated graph traversals. When you instead load all the raw vectors first and then build the index over the whole batch, the build can process points in a more cache-friendly order, the graph is constructed once instead of being repeatedly repaired, and the work is parallelizable across threads and segments. The rule of thumb is that bulk-loading with indexing disabled and indexing once at the end can be several times faster than incremental indexing during the load, and the gap grows with collection size.

The mechanism is the optimizer's indexing_threshold. When a segment's point count is below the threshold, the optimizer skips building an HNSW graph for it and queries fall back to a brute-force scan over that segment. Above the threshold, the optimizer builds the graph. So the standard bulk-load procedure is: raise indexing_threshold to a value larger than the total number of points you are about to load, perform the load, then lower indexing_threshold back to its normal value. That triggers a single indexing pass over the consolidated data. The same logic applies to memmap_threshold, which controls when a segment is moved to disk - raising it during the load keeps segments in RAM, which is faster if they fit, and lowering it afterward moves cold data to disk. There is a second reason to disable indexing during a load: if indexing is running concurrently, the optimizer is competing with the ingest path for CPU and I/O, so both the load and any concurrent queries get slower. Deferring the index removes that contention entirely.

The trade-off is ingest throughput against search quality during the load. While indexing is deferred, every segment is unindexed, so queries fall back to a linear scan. That is fine for a background migration or an initial load with no live traffic, but it is not acceptable if you are bulk-loading into a production collection that is serving users. In that case you either load in bounded batches (so only a fraction of the data is unindexed at any time), or you load into a new collection and swap an alias at the end. The common mistake is leaving the default indexing_threshold in place during a multi-million-point bulk load, which causes the optimizer to constantly build and merge segments, slowing both the load and any concurrent queries. The second mistake is forgetting to lower the threshold afterward - the collection looks fine because queries work, but they are all doing brute-force scans, and latency scales linearly with collection size. The third mistake is assuming that disabling indexing means writes are not durable. They are - they are in the WAL and in segments; the only thing missing is the graph. The alternative to the threshold-tuning approach is the two-collection swap: build a new collection with the final config, load it, then atomically move an alias. That is the safest pattern for production because it avoids any window where the live collection is unindexed. Version note: the exact field names (indexing_threshold, memmap_threshold) and their defaults have changed across releases, and in some versions the thresholds are interpreted per-segment rather than per-collection - verify on your version.

Version-dependent: in recent Qdrant releases the optimizer thresholds have been reworked and their defaults differ. Some versions expose an explicit way to disable indexing entirely for a period, and the interaction between indexing_threshold, memmap_threshold, and max_optimization_threads has changed. If you are running a large migration, benchmark the load on your version with your data rather than assuming a fixed speedup from the pattern.