Compute-Storage Disaggregation
Decoupling compute from storage in database/cloud architectures — driven by their differing cost, scaling, and statefulness profiles — enabling elastic scaling, cost efficiency, and fault isolation at the cost of new network-bound bottlenecks and weaker compute/storage fate-sharing.
Also known as: disaggregated architecture, log is the database, shared storage architecture, stateless compute, database disaggregation
How authors use it
Oldest first (extraction date when no publication date is known).
| Author | Their term | Their meaning |
|---|---|---|
| Presentation: Parting the Clouds: The Rise of Disaggregated Systems Murat Demirbas · 2026-07-30 | Log is the database | Aurora's design principle: ship only the write-ahead/redo log to storage (not the full materialized state), and have storage nodes reconstruct pages from the log — cutting network traffic and data movement. |
Documents (1)
- Presentation: Parting the Clouds: The Rise of Disaggregated Systems Murat Demirbas · 2026-07-30 source ↗ Reader 🖥️
Cloud economics (the differing cost, scaling, and statefulness profiles of compute versus storage) is forcing database architectures toward disaggregation, and this shift is not a novel invention but a rediscovery of Lamport's original three-role decomposition of Paxos (proposer/acceptor/learner) — so the tradeoffs, optimizations, and open problems of today's disaggregated systems can be understood, and addressed, through decades of prior consensus-protocol research.
Propositions touching this concept (2)
By publication month, oldest first (extraction month when no publication date is known).
2026-07
- explicitAurora's 'log is the database' innovation — shipping only the redo log to storage and letting storage materialize pages from it — is the shared foundational invention that subsequent disaggregated database architectures (PolarDB, TaurusDB, Socrates) generally built on or varied.
- explicitTrue serverless databases require disaggregation as a precondition, because stateless compute workers that can appear and vanish safely depend on shared durable storage for fast failover and cold start.
Open gaps (3)
- incompleteThe talk's central analogy (Paxos's proposer/acceptor/learner = disaggregated compute/log-store/page-store) is argued from role-count and role-function correspondence, but never examines whether the actual consistency and safety mechanisms engineered into commercial systems — Aurora's specific 4-of-6 storage quorum, PolarDB's 'parallel Raft' — were derived from, or are even formally equivalent to, Paxos's quorum-based correctness guarantees. It is left unclear whether this is a rigorous technical lineage or a structural resemblance noticed after the fact and narrated as history.Presentation: Parting the Clouds: The Rise of Disaggregated Systems — read next: Compare the Aurora and PolarDB architecture papers' own consistency arguments against Lamport's Paxos correctness proof, to see whether their quorum choices were derived from consensus theory or arrived at independently by systems engineers optimizing empirically for latency and durability.
- incompleteThe list of production disaggregated systems (Aurora 2015 through Amazon DSQL 2025) is presented as confirmatory evidence that disaggregation 'is already here' and validated, with no counter-examples, documented cost overruns, performance regressions, or teams that reverted from disaggregated to monolithic designs — a one-sided evidentiary base for what is framed as an economically inevitable trend.Presentation: Parting the Clouds: The Rise of Disaggregated Systems — read next: Look for independent benchmarks or critical retrospectives comparing Aurora/PolarDB/AlloyDB total cost of ownership and performance against self-hosted or lift-and-shift Postgres/MySQL, to test whether 'cloud economics demands disaggregation' holds outside an idealized cost model.
- illogicalThe 'ingrained fault tolerance' principle (build consensus into the database rather than depend on an external configurator) is asserted without reconciling that internalizing consensus reintroduces the coordination overhead that motivated separating log stores and page stores from compute in the first place. The author himself concedes the shared-log/virtual-log research branch he praises still depends on an external metastore ('I'll live with it'), which undercuts the principle's own claim to full self-containment without resolving the tension.Presentation: Parting the Clouds: The Rise of Disaggregated Systems — read next: Read Mahesh Balakrishnan's shared-log/virtual-log work for how it explicitly handles this exact tradeoff, rather than fully internalizing consensus — it may show that full self-containment is not achievable in practice and 'ingrained fault tolerance' is aspirational rather than a settled design principle.