How do you choose the right index type for a given Milvus workload?

Index selection in Milvus generally comes down to weighing dataset size, available memory, latency requirements, and acceptable recall against each other, since no single index type wins on every axis simultaneously.

1. Small datasets or when exact results matter - FLAT, brute-force search with no accuracy trade-off, acceptable when the dataset is small enough that the lack of an approximate speedup doesn't matter.
2. General-purpose, memory available - HNSW, a strong default for high recall and low latency across most workload sizes.
3. Memory-constrained, larger scale - IVF_SQ8 or IVF_PQ, quantized variants trading some recall for a substantially smaller memory footprint.
4. Very large datasets exceeding available RAM - DiskANN, designed specifically for datasets too large to fit comfortably in memory.
5. GPU hardware available, need for maximum throughput - GPU-accelerated indexes like GPU_CAGRA, for workloads that can leverage GPU parallelism for both index building and search.

In practice, teams often benchmark two or three candidate index types against their actual data and query patterns rather than choosing purely theoretically, since real-world recall and latency depend heavily on the specific vector dimensionality, distribution, and query load a given application actually sees.