From monolith to Lakebase to LTAP: rethinking the database from storage up
Databricks argues that externalizing Postgres storage eliminates core monolithic-database constraints, then extends the design to serve fresh analytics from the same durable data. Lakebase and LTAP separate transactional and analytical compute while unifying their storage layer.
From monolith to Lakebase to LTAP: rethinking the database from storage up
Author: Reynold Xin | Published: 2026-06-30 | Generated: 2026-07-04 | Domain: databricks.com
Tags: ‘#databases’ ‘#postgres’ ‘#lakebase’ ‘#ltap’ ‘#data-lakehouse’ ‘#analytics’
TLDR
Traditional databases couple the write-ahead log (WAL), data files, and compute on one machine, making durability dependent on disk behavior, scaling dependent on full physical replicas, and analytics disruptive to transactional workloads. Lakebase makes Postgres compute stateless by externalizing WAL replication to SafeKeeper and page storage to PageServer, while LTAP materializes the same operational data into open Parquet-based Delta/Iceberg tables for analytics. Rather than HTAP’s single-engine approach, LTAP uses specialized Postgres and Lakehouse engines with independent compute and a single, current, governed copy of data.
Key Takeaways
- Monolithic storage creates systemic constraints: Co-locating WAL and data files on one machine exposes commits to misconfigured or failed disks; read scaling and high availability require expensive full-database clones that replay WAL.
- SafeKeeper externalizes durable writes: Lakebase commits through Paxos-based quorum replication of WAL records rather than trusting one local disk flush. Databricks says this adds no meaningful latency versus a durability-conscious synchronous-replication setup.
- PageServer externalizes read storage: It streams WAL from SafeKeeper, asynchronously materializes database pages into cloud object storage, and reconstructs the latest page state from logs when necessary. Local memory and disk caches preserve typical read latency on cache hits.
- Lakebase claims performance and operational benefits: The SafeKeeper/PageServer architecture is reported to deliver up to 5× higher write throughput and 2× lower read latency, alongside elastic serverless compute, virtually unlimited object storage, simpler HA, and metadata-only database branching/cloning.
- LTAP removes the CDC second copy: PageServer transcodes Postgres rows into columnar Parquet as data is materialized, preserving Postgres values and MVCC history. Analytics queries read a current LSN, scan mostly materialized object-store data, then merge only recent unapplied changes from PageServer—without routing analytical reads through Postgres.
- Storage-layer unification differs from HTAP: LTAP retains mature, purpose-built engines—Postgres for ACID transactions and Lakehouse engines for analytics—avoiding a new all-purpose engine’s feature gaps, weak ecosystem, and shared-resource contention.
Images & Media
- Monolithic database architecture — Illustrates a conventional database where compute, WAL, and data files reside on a single machine.
- Lakebase read hierarchy — Depicts multi-layer caching between Postgres compute, local storage, PageServer, and object storage.
- CDC versus LTAP architecture — Compares replicated CDC analytics pipelines with LTAP’s single-copy, storage-layer approach.
Referenced Links
- What is Lakebase? — Overview of Databricks’ serverless Postgres database and its disaggregated architecture.
- Lakebase architecture delivers 5× faster Postgres writes — Claimed Lakebase throughput and latency benchmarks.
- ARIES paper — Foundational paper describing WAL-based recovery and transaction processing.
- PostgreSQL synchronous replication documentation — Guidance on synchronous replication and high availability.
- Databricks launches LTAP — Product announcement for Lake Transactional/Analytical Processing.
- Lakehouse//RT — Databricks’ real-time Lakehouse offering referenced as an LTAP analytics consumer.
- LTAP Data and AI Summit demo — Product demonstration of the LTAP architecture.