Disaggregated databases are becoming the answer to the demands of the cloud economy. We analyze why the separation of compute and storage changes the architecture and behavior of systems.
The system begins to degrade when compute and storage remain tightly coupled. They have different load characteristics: compute is expensive and volatile, while storage is cheap and growing. In monolithic and even early cloud architectures, this leads to excessive costs and inefficient scaling. For example, when data grows, compute must be scaled even if it is not needed. This violates the principle of separation of responsibilities and impacts cost efficiency.
The answer has been the architecture of disaggregated databases, where compute and storage are separated. This approach allows for independent scaling of resources: compute can be elastic, even down to scale-to-zero, while storage acts as a stable layer. This is a compromise between performance and economics. A new bottleneck emerges — the network, but modern technologies (high bandwidth, RDMA, SmartNIC) make this trade-off acceptable. As a result, the architecture begins to align better with the pay-per-use model.
Implementation relies on several key principles. Compute becomes stateless and interacts with storage over the network. Storage transforms into a shared layer with logical segmentation, such as Log Store and Page Store. Data writing occurs through a redo log, which is first replicated in a storage quorum and then confirmed to the client. This reduces the volume of data transmitted and lessens the load on the network. At the same time, part of the data materialization logic is moved into storage, complicating system evolution and requiring consistency between layers.
Architectures like Amazon Aurora demonstrate this approach in practice. The primary compute sends the redo log to storage and waits for confirmation from the quorum. Replicas (read-only nodes) can serve requests by materializing state from the logs. This reduces latency for reads and distributes the load. However, a new class of problems arises: how to minimize network round-trips, how to distribute CPU between compute and storage, and where to draw the lines of responsibility.
An additional layer of complexity is fault tolerance. In disaggregated systems, a compute failure does not affect storage. This accelerates recovery and simplifies operations. Compute nodes can be quickly recreated on top of shared storage. But the cost is a dependency on the network and the need to carefully design interaction protocols.
Interestingly, the ideas of disaggregation are not new. Roles in Paxos already effectively separated compute and storage responsibilities. This shows that modern cloud architectures often evolve from classical distributed systems concepts. The novelty here is not in the idea, but in the scale and economics.
From a practical standpoint, disaggregated databases have already become an industry pattern. Different implementations converge on basic principles: shared storage, stateless compute, and the network as the primary I/O channel. This confirms that the architectural shift is driven not by fashion, but by fundamental constraints and infrastructure requirements.
Metrics in the original data are not provided, but the qualitative effects are clear: improved cost efficiency, flexible scaling, and increased fault tolerance. At the same time, the price is an increase in system complexity and an enhanced role for the network as a critical resource.
Ultimately, disaggregation is a pragmatic choice. It does not eliminate all problems but shifts them to a more manageable plane. For architects, this means a shift in focus: from local I/O to network interactions, from monolithic nodes to distributed layers.