---
title: "From monolith to Lakebase to LTAP: rethinking the database from storage up"
description: "The post examines why monolithic OLTP databases become fragile and difficult to scale when compute, the write-ahead log (WAL), and data files share one machine. Using Postgres as its primary example, it contrasts local WAL durability and physical cloning with Lakebase, whose stateless Postgres compute externalizes those components into SafeKeeper and PageServer services. SafeKeeper replicates log records across a quorum through Paxos-based network replication, while PageServer applies the WAL and materializes data in cloud object storage. The resulting separation is presented as a way to improve durability, independently scale reads and writes, isolate workloads, and support high availability and branching without physical database clones. LTAP extends the design by making transactional tables directly queryable for analytics from a single governed copy, avoiding CDC or mirroring and allowing transactional and analytical engines to scale independently."
---

# From monolith to Lakebase to LTAP: rethinking the database from storage up

[Databricks](https://yomu.fyi/company/databricks) · Reynold Xin · Jun 30, 2026

**Type:** Explainer

## Summary

The post examines why monolithic OLTP databases become fragile and difficult to scale when compute, the write-ahead log (WAL), and data files share one machine. Using Postgres as its primary example, it contrasts local WAL durability and physical cloning with Lakebase, whose stateless Postgres compute externalizes those components into SafeKeeper and PageServer services. SafeKeeper replicates log records across a quorum through Paxos-based network replication, while PageServer applies the WAL and materializes data in cloud object storage. The resulting separation is presented as a way to improve durability, independently scale reads and writes, isolate workloads, and support high availability and branching without physical database clones. LTAP extends the design by making transactional tables directly queryable for analytics from a single governed copy, avoiding CDC or mirroring and allowing transactional and analytical engines to scale independently.

## Context

Traditional OLTP databases keep the WAL and data files on one machine, tying durability to local storage, requiring physical clones for scaling and availability, and causing analytical queries to contend with transactional workloads.

## Approach / What changed

Lakebase makes Postgres compute stateless by externalizing the WAL to the distributed SafeKeeper service and data files to PageServer, which materializes data in cloud object storage. LTAP uses the shared storage architecture so transactional and analytical engines can access one governed copy of the data without CDC or mirroring.

## Takeaways

- SafeKeeper uses Paxos-based network replication across a quorum to make WAL records durable without relying on a single machine’s disk flush.
- PageServer asynchronously applies WAL changes and materializes database pages in low-cost cloud object storage, separating data storage from Postgres compute.
- LTAP exposes Lakebase tables for analytics from the same data copy used by transactions, avoiding replication drift and allowing independent workload scaling.

**Tags:** [Architecture](https://yomu.fyi/topic/architecture), [Lakebase](https://yomu.fyi/topic/lakebase), [Postgres](https://yomu.fyi/topic/postgres)

- Source: [Databricks](https://www.databricks.com/blog/lakebase-ltap-rethinking-database-storage)
- Source URL: https://www.databricks.com/blog/lakebase-ltap-rethinking-database-storage
- Ingested by Yomu: 2026-08-30T16:59:43.977Z

[Read original post](https://www.databricks.com/blog/lakebase-ltap-rethinking-database-storage)