Storage/Compute Separation: The Cloud-Native Trade-off

Ask what "moving to the cloud" changed architecturally and the common answer — "we run on someone else's servers" — misses the structural shift. The one that actually reshapes design is this: storage and compute stopped being one machine. They became two resources you scale, and pay for, independently. This post is the reasoning behind that split, and a small repo that lets you measure when it's worth it.

Runnable companion: storage-compute-separation on GitHub. make up && make load && make query && make scaleout && make cost reproduces everything below on MinIO + DuckDB.

Coupled vs separated

A traditional database keeps the query engine and the data on the same box. Cloud-native analytics pulls them apart:

COUPLED (traditional DB)              SEPARATED (cloud-native)

┌──────────────────────┐             compute A   compute B   (stateless,
│ compute (queries)    │                  │          │        disposable)
│ ──────────────────── │                  └────┬─────┘
│ storage (data)       │                       ▼  query
└──────────────────────┘             ┌──────────────────────────┐
 scale one = scale both              │ object storage (the data)│
 pay 24/7 for peak                   │ cheap · durable · once   │
                                     └──────────────────────────┘
                                      scale compute 0..N on demand

• Coupled (Postgres/MySQL on a box, RDS): simple, low-latency, transactional. But to add a second heavy workload you fight for the same machine or copy the whole database — and you pay for peak-sized compute 24/7, even overnight when nothing runs.
• Separated (object storage + engines like DuckDB, Athena, Snowflake, BigQuery): storage is cheap and shared; compute is stateless and elastic. Ten teams get ten engines over one copy of the data, and compute billing stops when nobody queries.

What the lab shows

The storage tier writes a 2-million-row sales dataset as Parquet into object storage and walks away — the data is owned by no compute node. A stateless DuckDB engine then queries it straight from storage:

Scanned 2,000,000 rows from object storage in 356 ms
This compute node holds no data. Kill it and the data is untouched.

The payoff is the scale-out demo: three independent engines, three different team workloads, one stored dataset, zero data movement:

[finance   ] independent compute done in  299 ms
[growth    ] independent compute done in  245 ms
[operations] independent compute done in  148 ms
Storage was written once; compute scaled to 3 nodes and back to 0.

In a coupled world, that's three teams fighting one box — or three copies of the database.

The cost model — why "it depends"

Here's the part that matters for an architect. make cost prices both models for the same 500 GB across three usage shapes:

Scenario                     Coupled   Separated      Winner  Savings
---------------------------------------------------------------------
24/7 steady analytics           $279        $413     Coupled     32%
business-hours BI               $279        $108   Separated     61%
occasional / bursty             $279         $22   Separated     92%

Same data, opposite answers. Coupled cost is fixed — an always-on instance, billed every hour whether or not anyone queries. Separated cost is variable — cheap object storage always, plus compute billed only for the hours you actually run.

So the winner flips with the workload:

• Constant, heavy load → coupled can win: a committed always-on instance undercuts on-demand compute at a premium.
• Spiky or idle-heavy load → separation wins big: you stop paying compute the moment you stop querying.
• Storage is nearly free either way. Compute hours drive the decision — not storage, and not fashion.

All the rates are printed and editable; arguing with the assumptions is the actual skill, not the arithmetic.

The cost you take on

Separation is not a free upgrade — it's a distributed system:

• Every query crosses the network from compute to storage: more latency, new failure modes a single box doesn't have.
• Object storage is not a database — no transactions, no cheap single-row updates. It's built for large scans, not OLTP.
• More moving parts to secure and observe.

The instinct worth internalizing (straight out of DDIA): the cloud is inherently distributed, and separation means distributing your database. Worth it at scale or for spiky, multi-tenant analytics — wasteful when a single node still handles the job comfortably.

What I'd say in an interview

• Cloud-native's core structural change is storage/compute separation, not "it runs elsewhere".
• The economics are contextual — name the usage shape before naming the winner. A cost model beats an opinion.
• Separation buys elasticity and workload isolation, and bills you in latency and distributed-systems complexity. Reach for it when the workload's shape pays for that, and stay coupled when it doesn't.