Databricks' LTAP Bets 45 Years of Two-Database Architecture Is Wrong

For roughly 45 years, data teams have accepted a painful tradeoff: run a transactional database (Postgres, MySQL, Oracle) for your application, run a separate analytical system (a data warehouse or lakehouse) for your queries, and stitch the two together with ETL pipelines that are brittle, slow, and constantly drifting out of sync. At this year's Data + AI Summit, Databricks announced LTAP (Lake Transactional/Analytical Processing) , a new architecture that bets the entire premise of that two-system world is wrong.

The problem that nobody questioned

For roughly 45 years, enterprise data has lived in two separate worlds. OLTP databases like Postgres, MySQL, and Oracle handle live transactional work: taking orders, processing payments, updating records. OLAP systems handle analysis, dashboards, and machine learning. The bridge between them is ETL , extract, transform, load , which is expensive, slow, error-prone, and means you are always running on two slightly out-of-sync copies of the same data.

Bridging them meant building CDC pipelines that are brittle and prone to breaking under pressure. CDC, or Change Data Capture, is the technique of streaming a log of every database change into a separate analytics store. It works, but you pay for it in pipeline maintenance, replication lag, governance complexity, and the constant risk that your two copies have quietly diverged. Agents write code, make calls, and run loops at a pace human teams never could. The infrastructure that powered the last era of computing is now the bottleneck that no one can afford.

Lakebase: making Postgres stateless

To understand LTAP, you first need to understand Lakebase, Databricks' serverless Postgres product built on the Neon architecture. The key move is making the Postgres compute layer completely stateless by externalizing the two things that traditionally live on a single machine's disk.

In any traditional database, two structures matter most:

• The Write-Ahead Log (WAL): a sequential log of every committed transaction. Writes go here first because appending to a log is fast.
• Data files: the actual pages of data, updated asynchronously. These make reads fast by storing current state directly.

Almost every traditional database keeps its write-ahead log and data files on one machine's disk, which is the root cause of data loss risk, expensive read replicas and high-availability clones, and analytics queries that drag down transactions. Lakebase makes Postgres compute stateless by externalizing the log and data files into independent cloud services , SafeKeeper and PageServer , unlocking unlimited storage, elastic compute, durable writes, simpler HA, and instant branching, all with no meaningful added latency.