𝗡𝗲𝗮𝗿𝗹𝘆 𝗵𝗮𝗹𝗳 𝘆𝗼𝘂𝗿 𝗠𝗶𝗹𝘃𝘂𝘀 𝘀𝗲𝗮𝗿𝗰𝗵 𝗰𝗮𝗽𝗮𝗰𝗶𝘁𝘆 𝗺𝗮𝘆 𝗯𝗲 ...

When a collection grows through continuous https://t.co/8JDL2AQE5n

𝗡𝗲𝗮𝗿𝗹𝘆 𝗵𝗮𝗹𝗳 𝘆𝗼𝘂𝗿 𝗠𝗶𝗹𝘃𝘂𝘀 𝘀𝗲𝗮𝗿𝗰𝗵 𝗰𝗮𝗽𝗮𝗰𝗶𝘁𝘆 𝗺𝗮𝘆 𝗯𝗲 𝗴𝗲𝘁𝘁𝗶𝗻𝗴 𝗯𝘂𝗿𝗻𝗲𝗱 𝗼𝗻 𝘀𝗲𝗴𝗺𝗲𝗻𝘁-𝗹𝗲𝘃𝗲𝗹 𝗼𝘃𝗲𝗿𝗵𝗲𝗮𝗱. 𝗔𝗱𝗱𝗿𝗲𝘀𝘀 𝗶𝘁 𝘄𝗶𝘁𝗵 𝗙𝗼𝗿𝗰𝗲 𝗠𝗲𝗿𝗴𝗲 𝗖𝗼𝗺𝗽𝗮𝗰𝘁𝗶𝗼𝗻. When a collection grows through continuous writes, Milvus keeps each sealed segment indexed separately. During ingestion that makes sense — you don't want to rebuild indexes while data is still flowing in. After the data settles, fragmentation can remain. Queries fan out across the relevant sealed segments, and the per-segment overhead adds up: separate index searches, scheduling, result merging. The total data hasn't changed, but the query cost has. We measured this on a 1M-vector HNSW collection. One change — consolidating 3 segments into 1 with Force Merge Compaction: • 𝗤𝗣𝗦: ~𝟯,𝟬𝟬𝟬 → ~𝟱,𝟰𝟬𝟬–𝟱,𝟴𝟬𝟬 (roughly 1.8x QPS) • 𝗽𝟵𝟵 𝗹𝗮𝘁𝗲𝗻𝗰𝘆: down roughly a third • 𝗦𝗮𝗺𝗲 𝗵𝗮𝗿𝗱𝘄𝗮𝗿𝗲, 𝘀𝗮𝗺𝗲 𝗶𝗻𝗱𝗲𝘅, 𝘀𝗮𝗺𝗲 𝗱𝗮𝘁𝗮 That gap is the fan-out tax. Fewer segments means less overhead per query, and the CPU freed up serves more queries instead. Force Merge lets you reclaim that headroom with 𝗼𝗻𝗲 𝗽𝗹𝗮𝗻𝗻𝗲𝗱 𝗼𝗽𝗲𝗿𝗮𝘁𝗶𝗼𝗻 after ingestion wraps up — a single rebuild, then sustained gains for similar search workloads. 𝗦𝗲𝘁𝘂𝗽: 1M vectors, 768-dim, HNSW, single-node Docker Compose (16 cores / 64 GB), VDBBench Cohere 1M, Milvus 2.6.17 𝗙𝗼𝗿𝗰𝗲 𝗠𝗲𝗿𝗴𝗲 𝗶𝘀 𝗶𝗻 𝗽𝘂𝗯𝗹𝗶𝗰 𝗽𝗿𝗲𝘃𝗶𝗲𝘄. 𝗙𝘂𝗹𝗹 𝗲𝘅𝗽𝗲𝗿𝗶𝗺𝗲𝗻𝘁 𝗱𝗲𝘁𝗮𝗶𝗹𝘀 𝗶𝗻 𝘁𝗵𝗲 𝗯𝗹𝗼𝗴: milvus.io/blog/force-mer…