Why separate storage and compute in a cloud warehouse?

WHAT THIS TESTS This is an advanced check on whether you understand the architectural leap from tightly coupled MPP warehouses to the decoupled storage-and-compute model that defines modern cloud warehouses.

A GOOD ANSWER COVERS In a traditional shared-nothing MPP warehouse, each node owns a fixed slice of the data on its local disk, so storage and compute are bound together. Scaling means adding nodes and redistributing data, which is slow and disruptive, and all workloads compete for the same cluster. Modern cloud warehouses split into three conceptual layers. A storage layer keeps data in virtually unlimited, durable, cheap shared object storage, often in a columnar format, decoupled from any compute node. A compute layer consists of independent elastic clusters, sometimes called virtual warehouses, that each read the shared data and process queries; you can spin up, resize, or pause them on demand. A cloud services layer manages metadata, query optimization, security, and transaction coordination. The advantages are that compute and storage scale independently, multiple isolated compute clusters can run concurrently against the same data without contending, you pay only for compute while it runs, resizing needs no data reshuffling, and storage is effectively unbounded.

COMMON WRONG ANSWERS Describing it as just MPP moved to the cloud, missing that classic MPP nodes still own their data slice. Claiming separation hurts performance because compute reads remote storage; in practice caching and columnar pruning mitigate this. Ignoring workload isolation, a major benefit. Forgetting the economic shift to pay-per-use and pause-when-idle.

LIKELY FOLLOW-UPS How does caching hide the latency of reading from object storage? How do you isolate ETL from BI workloads? How does this enable zero-copy cloning or time travel? Where can the decoupled model still bottleneck?

ONE CONCRETE EXAMPLE A company runs a heavy nightly ETL on one compute cluster while analysts query the same tables on a separate cluster sized for interactive use. Neither slows the other because they share only the storage layer, and the ETL cluster auto-suspends when finished so it costs nothing while idle.