Databricks has published a technical deep-dive into Lakebase, its serverless Postgres database that fundamentally rearchitects traditional database storage to enable what the company calls LTAP (Lake Transactional/Analytical Processing).

The architecture addresses core limitations of monolithic databases by making Postgres compute stateless. Traditional databases store write-ahead logs and data files on a single machine, creating durability risks and scaling bottlenecks.

Lakebase externalizes these components into independent cloud services called SafeKeeper and PageServer. SafeKeeper handles the write-ahead log, while PageServer manages data files in cloud object storage.

Breaking the monolithic model

This separation eliminates several traditional database pain points. Read replicas no longer require full physical copies of the entire dataset. High availability doesn't demand synchronous replication across multiple complete database clones.

The stateless compute layer can be started, stopped and replicated freely since it no longer owns the data. This enables what Databricks calls "unlimited storage, elastic compute, durable writes, simpler HA, and instant branching."

LTAP extends this architecture further by storing operational data in open columnar formats that both Postgres and lakehouse engines can read directly. This means analytics queries run on the same fresh data that transactions just wrote, without requiring change data capture pipelines or maintaining separate copies.

Real-time analytics without compromise

Unlike HTAP (Hybrid Transactional/Analytical Processing) systems that attempt to unify both workloads in a single engine, LTAP unifies at the storage layer while preserving specialized engines for each workload type.

Analytical queries no longer contend with transactional traffic for compute resources. Heavy reporting queries or data cleanup operations can't degrade latency-sensitive OLTP performance.

The approach builds on research that began 16 years ago at UC Berkeley, where Databricks co-founders worked on Apache Spark. The team's frustration with existing OLTP databases' fragility and scaling limitations drove the Lakebase development.

Databricks positions this as solving the "data loss from misconfiguration" and "data loss from node loss" problems that plague traditional databases where commits depend on single-machine disk flushes and storage mounts.