Parting the Clouds: The Rise of Disaggregated Systems

Every database you learned on was a box. One process, one disk, local I/O, and a buffer pool sitting between them. Murat Demirbas's argument in this talk is that the box is being taken apart by economics rather than by computer science, and that the resulting architecture — stateless compute over shared storage, with the network in the middle — is not a novelty but a rediscovery of a decomposition Leslie Lamport wrote down when he described Paxos. His central thesis is that compute and storage have an inherent impedance mismatch, that the cloud's cost structure makes bundling them indefensible, and that once you separate them the hard problems are the classical distributed systems problems in new clothing.

Demirbas is a Principal Research Scientist at MongoDB Research. Before that he spent three years as a Principal Applied Scientist at AWS, where he says he worked on Amazon DSQL for two years, and sixteen years as a Computer Science professor at the University at Buffalo (SUNY). InfoQ's 47:00 recording is from QCon San Francisco 2025 and is dated July 30, 2026.

A note on sourcing: InfoQ's published transcript for this talk contains the presentation only and no audience Q&A section, so nothing below is drawn from audience questions. Throughout these notes, claims are the speaker's unless explicitly marked as writer's note, which is background I have added for readers who have not met a term before.

What You Will Learn

• Why compute and storage have an economic "impedance mismatch" that makes bundling them a bad deal in the cloud, and what disaggregation buys beyond elastic scaling.
• How the three eras of database architecture — monolithic, Raft-replicated monolith, disaggregated — differ, and why the middle era wastes replication.
• The concrete write and read paths of Amazon Aurora, Alibaba PolarDB, and Huawei TaurusDB, including where each one puts the storage engine and what that costs.
• Why "log is the database" reduces network traffic, and why splitting storage into a Log Store and a Page Store lets you prioritise durability over materialisation.
• How Lamport's proposer, acceptor, and learner roles map exactly onto compute, log servers, and page servers — and what replication factors that mapping implies.
• What compartmentalized Paxos and the shared-log abstraction each disaggregate, and the throughput result Demirbas reports for the former.
• The costs: network as the new bottleneck, remote I/O penalties, extra hops, and loss of fate-sharing leading to metastable failure risk.
• The mitigations the field already uses, and the immature-but-promising directions: pushdown compute, memory disaggregation over RDMA and CXL, LSM-based designs, and self-assembling databases.

Why Economics, Not Elegance, Drives This

Demirbas opens by refusing to frame disaggregation as a design improvement. It is a pricing consequence. Compute and storage have what he calls an inherent impedance mismatch across three axes: compute is costly while storage is cheap; compute demand fluctuates quickly while storage demand is stable and growing; and compute can be stateless while storage is inherently stateful. Resources that differ this sharply, he argues, do not belong together in one box.

The commercial consequence of ignoring this is that a vendor who ships one box containing both must sell them in fixed ratios. If a customer needs more storage, they are forced to buy compute along with it, and vice versa. The customer overpays for whichever resource they did not need, which Demirbas frames as both a violation of separation of concerns and a margin that a competitor will happily compete away. He invokes Jeff Bezos's line that "your margin is my opportunity" to make the point: the cloud is fundamentally about cost reduction, and a fixed compute-to-storage ratio is a visible margin sitting in the open.

What makes the alternative feasible is networking. Demirbas states that hundreds of gigabytes per second of bandwidth is now the norm inside data centres, an order of magnitude improvement over ten or fifteen years ago, and that RDMA, SmartNICs, and CXL all push in the same direction. Data centre architectures are already disaggregated; databases are catching up.

Writer's note on the enabling hardware, which the talk names without defining: RDMA (Remote Direct Memory Access) lets one machine read or write another machine's memory without involving the remote CPU or kernel network stack, which removes most of the per-message software overhead. A SmartNIC is a network interface card with its own programmable processing, used to offload networking, storage, and security work from the host CPU. CXL (Compute Express Link) is a cache-coherent interconnect layered on PCIe that lets a CPU address memory attached to another device as if it were local. Demirbas returns to CXL in the future-work section.

What You Actually Get

The benefits Demirbas lists split into scaling, pooling, and operations, and he is careful that the last two get less attention than they deserve.

On scaling, disaggregation lets you scale compute up to a better box, which helps latency; scale out horizontally for more aggregate bandwidth and sharded parallel request processing; and — the one he emphasises most — scale down to zero. Scaling compute to zero is what makes genuine pay-per-use possible, and he is blunt that this is the whole point: "the customer value proposition is there, pay-per-use. The rest is just history and details."

On pooling, separating the storage tier lets it be multi-tenant, so I/O capacity and network capacity are pooled across customers and utilised better rather than sitting idle inside one tenant's box.

On operations, disaggregation gives fault isolation. When a node crashes you lose compute or storage, not both. Compute nodes are cheap to stand up over shared storage, so recovery is fast and operations are simplified. His summary line is that disaggregation "turns databases from heavy stateful boxes they were once, into lightweight elastic services running over shared storage." He revisits and partly walks back the fault-isolation claim at the end of the talk; see Trade-offs and Limitations.

Three Eras of Database Architecture

Demirbas structures the architecture section as three phase shifts.

Monolithic is "your dad's database," unchanged in shape since the 1970s: one process, one disk, local I/O. He names Postgres and MySQL as the archetypes.

Raft-replicated monolith is how the industry first got databases into the cloud: take the monolith and, as he puts it, "slap Paxos or Raft on them" for availability and durability. You run a replicated group of whole monolithic databases. One becomes primary, the consensus protocol prevents split-brain, and followers apply the log and serve reads. For horizontal scalability you run several such groups and layer two-phase commit across them for distributed transactions.

His verdict is that this works but is a hack, because it does not solve disaggregation at all — compute and storage are still fused inside each box, and you now have three boxes. The group is treated as "a virtually infallible node." The economic problem is replication compounding: if the underlying storage is already replicated by the cloud provider, you pay for that replication three times over. His concrete example is a three-member Raft group where each member uses EBS, which the cloud already replicates three times: that is nine copies of the storage plus three-way replication of transactions. Local NVMe drives avoid the double replication but are themselves costly.

Writer's note: EBS is AWS's network-attached block storage; the "already replicated" property is what makes the nine-copy arithmetic work. NVMe here means instance-local SSD, which is fast but not independently durable, hence the trade-off.

Disaggregated separates ephemeral compute from storage, and further separates storage into a Log Store and a Page Store. Because durability now lives in the storage tier, you no longer need three compute replicas to get three-way durability. A primary plus a closely-following failover secondary is enough. That single observation — three computes collapse to two, without losing durability or availability — is the first benefit Demirbas asks the audience to read directly off the architecture diagram.

Disaggregated Databases Are Already Shipping

Before going deeper he grounds the discussion in production systems, with the years he gave for each.

The shared themes across all of them are shared storage, stateless compute, and — the critical one — the network replaces local I/O. Every access from compute to storage crosses a network hop, and Demirbas says this single fact shapes every subsequent design decision. Durability comes from log replication in the short term and snapshots to S3 or another object store in the long term. Availability comes from the Page Store serving buffers to compute nodes. His framing for the whole model: "data center is the new computer," with the network layer as its backplane.

Three Architectures in Detail

Demirbas walks three systems to show that they answer the same question — how do you materialise pages when the state lives across a network — with different placements of the storage engine.

Aurora: Log Is the Database

Aurora's main innovation, which later architectures mostly followed, is that only the redo log crosses the network from compute to storage. The storage tier materialises pages from that log.

Writer's note: a redo log (or write-ahead log, WAL) is the sequential record of physical changes a database writes before applying them to data pages. It is much smaller than the pages it describes, which is exactly why shipping it instead of the pages saves bandwidth.

The write path, as described: the primary is always the sole read-write node, and you can have as many read-only secondaries as you like. On a write, the primary does not acknowledge to the client until the redo log record is replicated to a quorum of storage nodes. Aurora's quorum is four out of six, chosen to tolerate f = 2 failures. Once four of six reply, the primary acknowledges.

The read path has two sources. The primary can serve reads directly. Secondaries also receive the redo log from the primary and opportunistically materialise pages from it into their buffers, serving reads from there; if a secondary does not have a page, it fetches it from storage.

Demirbas then raises the obvious objection: if storage materialises pages, does storage have CPU? Yes, but limited. Compute nodes have far more CPU and are the part that scales elastically; storage nodes have some CPU, used opportunistically. Compute nodes also have some local storage, but not mounted durable volumes — "you don't need them."

The second objection is subtler: how does storage know how to turn redo records into pages? Aurora's answer, in his words, was to do "a surgery on MySQL," later Postgres, moving roughly half of the materialisation logic down into the storage nodes. He is explicit that this is not ideal: every new version of the upstream database means you "have to tend to those wounds, stitch them up." The design is excellent at being network-cognizant and expensive in ongoing engineering maintenance.

PolarDB: Keep the Engine at Compute, Pay in Bandwidth

Alibaba's PolarDB refuses the surgery. MySQL and its InnoDB storage engine both live at the compute tier. The primary ships the redo log to read-only nodes, and because those nodes also run InnoDB, they can materialise state, follow the primary, and serve reads.

The cost is on the storage side. Since storage nodes do not run InnoDB, they cannot materialise anything, so the primary must push the state pages as well as the redo log. Pages are needed at storage for availability: when a read-only node lacks a page in its buffer, it must read it from storage. That is substantially more network traffic than Aurora's log-only path. Demirbas notes Alibaba's response is partly to spend on hardware — they built PolarFS, a distributed file system, and push data over RDMA.

PolarDB's protocol contribution is parallel Raft. Raft serialises everything, which Demirbas says is not strictly necessary: if two operations do not touch the same keys, they do not need to be ordered relative to each other, so a parallel variant is possible. Their WAL replication uses a quorum of two out of three. He also highlights a design property: the PolarFS layer is oblivious to what it is replicating — it is opaque to database internals. That is the mirror image of Aurora, where the storage tier is deeply aware of them.

TaurusDB: Split the Storage Tier and Prioritise the Log

TaurusDB pushes the Aurora lesson further. Demirbas describes it as close to Microsoft's Socrates but simpler, with fewer moving parts. Its innovation is to split storage into a Log Store and a Page Store, and to prioritise the log.

That prioritisation shows up in how the log is replicated. Rather than a conventional quorum, TaurusDB uses custom replication with scattered I/O: the primary picks three storage nodes, asks them to replicate, and gives them a time budget. If one lags, the primary invalidates that attempt and picks a different three. Demirbas contrasts this with the usual approach — "we use quorums to get rid of tail latency, but this also works" — and says he is comfortable with it because the system has a time budget and moves on rather than stopping to repair: "we are in a hurry not to fix things."

Once the log is replicated, the write is acknowledged. Only afterwards is the log forwarded to the Page Store, which runs a storage engine to materialise pages. The Log Store also forwards the log to read-only nodes so they can materialise and serve reads.

The common shape across all three, in his summary: a primary compute node that reads and writes, followers that only read, log-is-the-database as the default, and a Page Store so that buffers can be served on demand.

Architecture and Data Flow

The following diagram renders the TaurusDB write and read paths as Demirbas described them. Labelling note: this is my redrawing of the speaker's described architecture, not a slide reproduced verbatim; the ordering and the components are his, the visual arrangement is mine.

flowchart TD
    C[Client] -->|write| P[Primary compute, read-write]
    P -->|1. redo log, scattered I/O with time budget| LS[Log Store]
    LS -->|2. replicated| P
    P -->|3. acknowledge write| C
    LS -->|4. log forwarded asynchronously| PS[Page Store, materializes pages]
    LS -->|4. log forwarded| RO[Read-only compute nodes]
    RO -->|page miss| PS
    PS -->|long-term durability| OS[Object store snapshots]
    C -->|read| RO

The single most important property to read off this picture is that the acknowledgement at step 3 depends only on the Log Store. Page materialisation is off the critical path. That is the concrete meaning of "prioritise the log," and it is why the Log Store / Page Store split is a latency decision rather than a storage-organisation decision.

Paxos Did It First

Demirbas asks the audience for five open-minded minutes on a claim he flags as deliberately provocative: did Lamport invent disaggregation before it was cool?

When Lamport described Paxos, he described it in terms of roles rather than machines. A client sends a request to a proposer; the proposer talks to acceptors; once a quorum of acceptors accept, the value goes to learners, which materialise the state and, in Lamport's formulation, send the response back to the client.

Writer's note for readers who have only seen Raft: Raft presents consensus as a protocol between uniform servers that are simultaneously leader-or-follower, log holders, and state machines. Lamport's original presentation kept those three jobs as separate logical roles, which is precisely the point Demirbas is making.

The mapping he draws is one-to-one:

What happened historically, he explains, is that in the Multi-Paxos paper Lamport noted the roles could be compacted into one node for efficiency — and that is exactly what the industry did, because it was building shared-nothing systems. Raft "squished them all" together, so a primary sends to two followers that are simultaneously acceptors, learners, and replicas. Demirbas's point is that this collapse was an optimisation for a hardware regime that no longer holds, and the uncollapsed form "is the recipe for disaggregated system."

Why the Analogy Earns Its Keep

He anticipates the "so what?" and gives two payoffs.

The first is replication factors. In the role decomposition, proposers only need f + 1 members to tolerate f failures, and learners only need f + 1. Only acceptors need 2f + 1, because that is where quorum intersection and split-brain avoidance live. Raft's uniform 2f + 1 therefore over-provisions the proposer and learner functions. More broadly, he points to two decades of Paxos research — flexible quorums, reading from replicas, throughput optimisations, some of it his own — as directly applicable to disaggregated storage, and says the field should be borrowing from it rather than rediscovering it.

The second is a design critique. The disaggregated architectures surveyed above all assume an external configurator that decides when a secondary becomes the primary. Demirbas objects that this decision comes from outside the system, and argues for ingrained fault tolerance: be self-contained, because "every dependency is a problem." His prescription is that consensus should be built into the disaggregated database service itself rather than delegated to a separate coordination service.

The Shared-Log Branch

One branch of Paxos work did not collapse the roles: the shared-log abstraction, which Demirbas attributes to Mahesh Balakrishnan's work at Meta and subsequently at Kafka and Confluent. The database is maintained over a virtual log composed of loglets. The virtual log maps logical addresses to physical loglets of finite size via a versioned metastore.

The property that makes this powerful is that you can switch loglets — and with them the acceptor configuration — on the fly, at loglet boundaries. Demirbas cites Balakrishnan using this to migrate Meta control planes from ZooKeeper to Raft-or-Multi-Paxos-based consensus live, and calls it amazing. It does retain some dependence on a configurator, which he says he can live with. In terms of the role decomposition, the shared-log design squishes proposers and learners together into "the database" while keeping acceptors separate, with I/O scattered across them, and the log advancing through fixed-size loglets.

Compartmentalized Paxos: Disaggregate Further

Demirbas then describes his own line of work, published with collaborators at Berkeley as compartmentalized Paxos — which, he says, they could equally have called disaggregated Paxos. It adds layers rather than removing them:

• The leader is split into proposers and a proxy leader layer. The proposer only orders values; the proxy leaders handle I/O. His rationale is that I/O fan-out and fan-in is what kills a leader, so separating ordering from message handling removes the bottleneck.
• The acceptors are disaggregated using the flexible quorum result inside the protocol itself, rather than through an external metastore. Separate write and read quorums are used for leader maintenance rather than for split-brain avoidance. Because this is protocol-level, reconfiguration granularity is per-decision rather than per-loglet, so I/O can be scattered across acceptors at much finer granularity.
• Learners can be added independently when you need more read capacity. "We could even disaggregate further to have proxy leaders" — the proxy-leader layer is itself independently scalable.

Writer's note on flexible quorums: the underlying result is that the two phases of Paxos do not need identical quorums — they only need to intersect with each other, not within themselves. That is what permits asymmetric read and write quorum sizes. Demirbas explicitly declined to go into the detail in the talk.

The reported result: on the same codebase, multi-Paxos throughput went up eight times. He attributes this to the power of specialisation — leaders were the bottleneck, proxy leaders solved that; reads were the next bottleneck, more learners solved that. Treat this as the speaker's reported experimental result for his own system rather than a general guarantee.

He immediately flags the catch, and uses it as the bridge to the trade-offs: too many hops. What about latency?

Trade-offs and Limitations

The Network Is the New Bottleneck

The core cost is stated plainly: disaggregation shifts the bottleneck from CPU and disk to the network, and further disaggregation crosses the network more times. The quantitative claim Demirbas gives is that remote I/O has roughly three times worse latency and four times less bandwidth than local SSDs. He frames the whole decision as a cost-benefit analysis you must run yourself: the costs are network latency, bandwidth charges, and I/O amplification; the benefits are elastic scalability, pooling of compute, storage and memory, and fault isolation with faster failover.

Latency shows up in three specific places: committing the log to shared storage, fetching pages that are not in a local buffer, and synchronisation and cache coherence costs between nodes.

Where Throughput Contention Appears

Demirbas identifies contention between the log and data pages, and contention between logs. His framing is that these are not new problems — the Paxos analogy is precisely the argument that the same principles apply — and that several mitigations are already present in the architectures surveyed above.

Losing Fate-Sharing

The most interesting caveat is the one he saves for the end, where he says directly: "I lied to you a little bit." Fault isolation is real — you no longer lose compute and storage together — but you pay for it by losing fate-sharing. More components mean more moving parts and more places where a node's picture of the system trails reality. Those delays in learning about failures can let failures propagate across layers.

The specific risk he names is metastable failure, which he calls a new area of research, and he raises the correctness question for dynamically composed systems: how do you vet an architecture that assembles itself for metastability? Simulation looks like a promising approach, but he says the science of metastability is still being developed. His summing-up is that "only the paranoid survive in this distributed systems business."

Writer's note: a metastable failure is one where a system, after a trigger has passed, remains stuck in a degraded state sustained by its own feedback — retries, timeouts, and queue growth consuming the capacity that would let it recover — so that removing the original cause does not restore service. Demirbas named the concept without defining it.

Coordination and Failure Modes Change Shape

Shared-nothing designs assumed private logs, and most distributed protocols were designed against that assumption. With shared storage replacing private logs, agreement no longer has to be reached by nodes exchanging messages; it can be log-mediated. His examples: commit or consensus by a compare-and-swap into a shared log, citing MemoryDB; leader election performed by writing to the log and thereby fencing off other would-be leaders; and bringing up new nodes purely by replaying the log for learning and recovery. He leaves it as an open question what the right coordination protocols are for this model.

Mitigations That Already Work

Cutting Latency

Demirbas lists the levers without dwelling on them:

• Buffers. Read-only nodes with large buffers materialise pages locally and serve them without a network round trip.
• Prefetching. Observe access patterns and fetch pages before they are asked for, so the fetch is off the critical path.
• Pipelining. OS-level and thread-level I/O tricks.
• Faster fabrics. RDMA is now commonplace and CXL is becoming a thing.
• Custom coordination protocols. His worked example is two-phase commit: instead of the coordinator broadcasting prepare and then broadcasting commit, run the prepare phase sequentially in one direction around the participants and the commit phase back the other way, finishing in one round trip. The general principle is that changing the communication topology, not just the message count, is where the wins are.

Cutting Traffic

• Log-as-database, which he credits Aurora with, cut data movement by 2.5x.
• Prioritise log traffic over page I/O, the TaurusDB lesson, since page materialisation can proceed asynchronously.
• Smart filter replay within log traffic itself.
• Scatter I/O across storage nodes and acceptors to avoid head-of-line blocking on any one of them.
• Push computation down to the data, covered next.

Future and Ongoing Work

Demirbas is careful to define what "future" means here: not that these do not exist, but that they are less mature or have fewer production examples.

Pushdown Computation

Taurus Near Data Processing (NDP) is his worked example, with Amazon Redshift and Snowflake cited as also having forms of this. For a scanned query, compute nodes convert pushdown predicates — filters, projections, aggregates — into LLVM bytecode and send it to the Page Stores. Page Stores execute it on a best-effort basis: if a node is under load and lacks the CPU, it skips the pushdown and returns whole pages. If it can, it JIT-compiles and executes the code to drop rows, trim columns, and emit partial aggregates early. Instead of shipping the whole scanned page range, far fewer bytes cross the network. The reason this fits the disaggregated model specifically is that the storage tier already has some CPU that would otherwise sit idle — utilisation again, which he ties back to the Bezos framing.

Memory Disaggregation

Storage has been untied from compute, but compute is still tied to memory: if you need more RAM, you buy more compute. Demirbas cites the statistic that 50% of DRAM in data centres is wasted by static provisioning, and argues the same pooling logic should apply.

The RDMA-based version lets compute nodes access a shared elastic buffer pool held in other compute nodes' memory. Fetching a page from a peer's RAM rather than from storage cuts latency and improves throughput, and effectively grows your memory pool elastically. He cites PolarDB Serverless as having done memory disaggregation with shared memory, while noting it is not yet commonplace and that people are still debating the cost-benefit analysis — which is why he files it under future work. RDMA itself he describes as "not as mature," with problems still to solve.

CXL is the newer option. The CXL fabric makes the CPU treat remote memory as local memory, and Demirbas says log-store semantics work over it, achieving six times lower latency than RDMA. The catch is scope: CXL confines you to a rack, whereas RDMA reaches across the data centre. That is a genuine architectural choice rather than a strict improvement.

He also mentions Oracle Exadata using more expensive persistent memory to guarantee redo log durability, as another instance of specialising the hardware to the role.

Disaggregation Enables Re-unification

A counterintuitive consequence: the discipline of a shared storage layer makes it easier to unify things on top of it. His example is Google AlloyDB unifying OLTP and OLAP, so analytics run against the freshest data instead of a separately maintained analytical cluster. The shape is the familiar one — a primary read-write node, read pool nodes that are read-only — but the read pool nodes carry both a columnar engine, which can use vectorized processing, and a row engine, on the same compute node, giving hybrid transactional/analytical processing. Storage sits on a distributed file system; where PolarDB uses PolarFS, AlloyDB uses Colossus.

An Ecosystem-Level Example: Rockset's ALT

Disaggregated RocksDB via Rockset shows disaggregation at the level of an entire data pipeline. The ALT architecture stands for Aggregators, Leaf nodes, Tailers, and disaggregated RocksDB spans both the compute and shared storage nodes, with writes entering from one side and reads from the other:

• Tailers tail Kafka logs to pick up real-time writes.
• Leaves build columnar inverted indexes from what the Tailers deliver.
• Aggregators run read-only distributed SQL queries over the indexed shards.

The property Demirbas highlights is that this cleanly isolates bursty ingest from indexing and from bursty querying — three workloads with entirely different resource profiles that would interfere inside one box.

LSM Trees and the Road to Serverless

Everything discussed so far assumed B-trees. Demirbas argues LSM trees are a much better fit for disaggregation because they write immutable SSTs. Immutability means the files can be shared safely, so compaction can run on any node. B-trees, by contrast, require random remote writes and page coupling, which are exactly the operations you do not want to send across a network. He says more work on disaggregated LSM designs is needed and that it is happening.

Writer's note: an LSM (log-structured merge) tree buffers writes in memory and flushes them as sorted, immutable files — SSTables — which background compaction later merges. B-trees update pages in place, which is where the coupling and random-write requirements come from.

This connects directly to serverless. "For a truly serverless database, you need a disaggregated database first." The serverless idea depends on stateless compute, stateless compute depends on shared storage, and remote pages and logs are what let workers appear and vanish safely. The consequences are that any worker can serve any shard, failover is fast, and cold start is low.

Open Questions

Demirbas closes the technical content with two questions he considers open. The first is self-assembling database management systems: can a DBMS auto-configure its compute, memory, and storage as workloads shift? He argues auto-tuning is going to be necessary specifically because of agentic workloads, which he says produce bursts thirty times worse than normal traffic — "when an army of agents start hitting your databases, how are you going to deal with them?" The second is hardware exploitation: AI investment is producing new hardware, and disaggregation gives you "the gift of specialization" to use it. He mentions recently seeing a GPU-based version of DuckDB as one example of that direction.

Practical Takeaways

• Do the replication arithmetic before choosing a topology. If your storage layer already replicates, running a three-node consensus group of full database instances on top of it multiplies copies you are paying for. Count total copies of bytes, not nodes.
• Decide deliberately where the storage engine lives. Aurora puts materialisation logic in the storage tier and pays a permanent upstream-merge tax; PolarDB keeps the engine at compute and pays in network bandwidth for shipping pages. There is no free option, and this is the single decision that most shapes the rest of the design.
• Get the log off the critical path from everything else. Acknowledge writes on log durability alone and let page materialisation proceed asynchronously.
• Treat the network as your budgeted resource. Once every access is remote, design reviews should ask how many crossings a request makes, not how many CPU cycles it costs.
• Use the role decomposition as a sizing tool. Ordering, durability, and serving state have genuinely different fault-tolerance requirements, so provisioning all three at 2f + 1 is over-provisioning two of them.
• Prefer built-in reconfiguration to an external configurator where you can, on the grounds that each external dependency is another failure mode.
• Consider log-mediated coordination primitives. Compare-and-swap into a shared log can replace message-passing agreement for commit and leader election once shared storage exists.
• Prefer LSM-based storage engines for disaggregated designs, because immutable files can be shared and compacted anywhere, unlike in-place B-tree updates.
• Push filters and aggregates to storage when storage has spare CPU, but make it best-effort with a full-page fallback so an overloaded storage node degrades instead of stalling queries.
• Choose RDMA versus CXL on scope, not just latency. CXL is faster but rack bounded; RDMA reaches the whole data centre.
• Plan for agentic traffic patterns, given the reported thirty-fold burstiness relative to normal traffic.

Key Terms

• Disaggregation — Separating a system's resources so each can be provisioned, scaled, and failed independently; here, splitting compute from storage and splitting storage into log and page tiers.
• Impedance mismatch (compute vs storage) — Demirbas's term for the fact that compute and storage differ in cost, demand volatility, and statefulness, so bundling them forces customers into ratios they do not want.
• Log Store — The storage component that durably persists the write-ahead or redo log. In the Paxos mapping, the acceptor.
• Page Store — The storage component that materialises the log into data pages and serves them to compute nodes. In the Paxos mapping, the learner.
• Log is the database — The design where only log records are shipped from compute to storage and the storage tier reconstructs pages from them.
• Loglet — A finite-size physical log segment in the shared-log abstraction; a virtual log maps logical addresses onto a sequence of loglets via a versioned metastore, allowing configuration changes at loglet boundaries.
• Proxy leader — In compartmentalized Paxos, a layer that handles message fan-out and fan-in on behalf of the proposer so that I/O does not bottleneck ordering.
• Flexible quorums — The Paxos result allowing different quorum sizes for the protocol's two phases, since only cross-phase intersection is required.
• External configurator — A separate service that decides membership and primary/secondary roles; Demirbas argues consensus should instead be ingrained in the database service.
• Fate-sharing — The property that co-located components fail together. Disaggregation deliberately removes it to gain fault isolation, at the price of delayed and partial failure knowledge across layers.
• Near Data Processing (NDP) / pushdown — Shipping query fragments to the storage tier for execution so that less data crosses the network.
• ALT (Aggregators, Leaf nodes, Tailers) — Rockset's decomposition separating ingest, indexing, and query serving into independently scalable tiers.
• SST (sorted string table) — The immutable on-disk file produced by an LSM tree; immutability is what makes remote sharing and node-agnostic compaction safe.

The talk lands on a synthesis rather than a recommendation. The future Demirbas sketches is fabric-aware databases that self-assemble from specialised microservices over a data centre treated as one giant computer — but his repeated insistence is that the challenges of that world are the classical distributed systems challenges, which is exactly why he asked the audience for five open-minded minutes on Paxos. He closes with an aphorism he attributes to "the famous industrialist Emerson," to the effect that there are many methods but few principles, and that mastering the principles lets you pick your methods while attempting methods without principles leads to trouble. The disaggregation wave gives you many new methods; the principles that tell you which to pick have been written down for decades.

Reference: Murat Demirbas, Parting the Clouds: The Rise of Disaggregated Systems, QCon San Francisco 2025, published by InfoQ on July 30, 2026.