How do you optimize Milvus for cost at billion-vector scale?

At billion-vector scale, cost is typically dominated by memory (for loaded indexes) and compute (Query Node count), so optimization mostly means reducing how much has to stay in expensive, fast memory without unacceptably sacrificing recall or latency.

• Use quantized or disk-based indexes where appropriate - IVF_PQ, or DiskANN for the largest collections, trade some memory footprint for a small recall cost, often a favorable trade at scale.
• Leverage tiered storage - automatically classify data by access pattern, keeping frequently-queried "hot" data in fast storage/memory while colder, rarely-accessed data moves to cheaper storage tiers.
• Right-size replica count - more replicas improve throughput and fault tolerance but proportionally increase memory cost; match replica count to actual concurrent query demand rather than over-provisioning by default.
• Scope queries with partitions - loading and searching only the relevant partitions for a given workload avoids paying to keep irrelevant data resident in memory.
• Release collections and partitions not actively in use - especially relevant for multi-tenant deployments with many collections where only a subset are queried at any given moment.
• Evaluate 1-bit or low-bit quantization techniques - newer quantization approaches can substantially reduce memory footprint with a smaller recall penalty than older quantization methods, worth evaluating specifically for very large, cost-sensitive deployments.

The general principle is matching resource commitment to actual access patterns rather than treating all data uniformly: most large-scale datasets have a long tail of rarely-queried data that doesn't need the same memory-resident, fully-replicated treatment as the smaller, frequently-accessed "hot" portion.