Why does Milvus separate compute and storage in its architecture?

Coupling compute and storage tightly, where the same nodes both hold data on local disks and perform query processing, forces the two to scale together even when their actual demands diverge: a workload might need much more query throughput without needing proportionally more storage, or vice versa for a write-heavy, rarely-queried archive.

By separating them, storage lives durably in object storage (S3, MinIO, and similar), which scales essentially independently of any specific compute node, while compute resources, Query Nodes, Data Nodes, Index Nodes, can each be scaled up or down based on their own specific bottleneck without needing to move or re-shard the underlying data. This also directly improves fault tolerance: since data durability lives in object storage rather than on any individual compute node's local disk, losing a Query Node doesn't risk losing data, it just means that node's in-memory search capacity needs to be replaced.

The trade-off is added architectural complexity, more distinct services to deploy, coordinate, and monitor, than a simpler, tightly-coupled single-node design would require, which is a genuine cost that matters more for small deployments than for the large-scale, elastic-demand workloads this separation is specifically designed to serve well.