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.

In Lakebase, the WAL is replaced by SafeKeeper, a distributed service that replicates log records across a quorum of nodes using Paxos-based consensus (a distributed agreement protocol that ensures data is durable even if individual nodes fail). The data files move to PageServer, which materializes pages into cheap cloud object storage. Due to how Postgres works internally, the combination of SafeKeeper and PageServer can lead to 5x higher write throughput and 2x lower read latency.

The practical wins from this disaggregation are significant:

• Unlimited storage: data lives in object storage, not a provisioned disk
• Scale to zero: stateless compute can spin down completely when idle
• Instant branching: cloning a production database becomes a metadata operation, not a physical copy , sub-second instead of hours
• Simpler HA: failover no longer means promoting a physical replica; the durable state already lives in a replicated storage layer
• Zero data loss: durability is guaranteed by Paxos replication, not by whether a single disk flushed correctly

Lakebase already serves thousands of customers, including Block, Ensemble, Superhuman, and Zillow, and handles 12 million database launches per day. Databricks claims roughly 80 percent of the databases on Lakebase are already being created by agents rather than people.

LTAP: one copy to rule them all

Lakebase already solved the operational database problem. LTAP is what happens when you realize the same storage layer can serve analytics too , without a second copy.

LTAP goes further by storing operational data once in open columnar formats like Delta and Iceberg, stored as Parquet, that both Postgres and Lakehouse engines read. Analytics runs on the same fresh data transactions just wrote, with no CDC pipeline, no second copy, and no slowdown to the transactional workload.

The mechanism is elegant. As the PageServer materializes pages into object storage, it simultaneously transcodes Postgres's row-based data into Parquet's columnar layout. The approach automatically converts PostgreSQL row-based data into columnar Delta Lake and Apache Iceberg formats as data is written into Lakebase. Analytical engines can then query that same data directly without CDC pipelines, ETL jobs, or data copies.

How freshness works without touching Postgres

The hardest problem in any "just read from the lake" design is freshness. If analytics reads from object storage, what about data written a millisecond ago that hasn't been materialized yet?

LTAP handles this with a two-step read:

1. The analytical engine asks Postgres for the current LSN (Log Sequence Number , a pointer to the exact position in the WAL). This is a cheap metadata call.
2. The engine reads the bulk of the data directly from object storage. For the small tail of very recent changes not yet materialized, it fetches those from the PageServer and merges them on top.

The result is a consistent, fully up-to-date snapshot of the data , and Postgres itself serves none of the analytical read traffic beyond returning a single number. Transactional workloads run in standard Postgres with full ACID semantics, completely unaffected by whatever analytical queries are running in parallel.

There's also a storage efficiency bonus: columnar data compresses far better than row data, often by more than 10x, so the format that makes analytics fast also makes the storage path substantially cheaper.

Why this isn't HTAP

If you've been around the database world, HTAP (Hybrid Transactional/Analytical Processing) will come to mind immediately. SAP HANA, Oracle, and others tried this for years. They mostly failed in practice because they forced both workloads into a single engine, trading performance on one side for gains on the other, and because they relied on proprietary storage that locked customers in.

Databricks is taking a different approach. Instead of building one engine that tries to do everything, they're building one storage layer that multiple specialized engines can operate against. Lakebase handles PostgreSQL transactions, the Lakehouse handles analytics, Lakehouse//RT handles low-latency serving, and they all operate on the same governed copy of Delta or Iceberg data.

The distinction matters because each engine stays optimized for its job. Postgres doesn't have to become a columnar engine. Spark doesn't have to become a transactional database. The unification happens underneath both of them, at the storage layer.

What's new on top of LTAP

LTAP doesn't ship alone. Databricks announced several capabilities alongside it:

• New cross-cloud, cross-region disaster recovery lets organizations build more resilient data architectures. New git-style branching and snapshots enable safe experimentation against production data, while autonomous database operations let agents monitor health, detect slowdowns, propose indexes, and assist with recovery.
• Lakehouse//RT is a real-time analytics product powered by a new compute engine called Reyden, delivering sub-100ms latency at high query volume directly on governed Delta Lake and Iceberg tables, collapsing what used to require a separate real-time serving tier.
• Databricks plans to open source an LTAP Writer Library that converts PostgreSQL data directly into Parquet-based columnar formats, making the LTAP storage layer accessible to the broader ecosystem.

Who should pay attention

LTAP is most immediately relevant if your team maintains any of the following:

• A CDC or "zero-ETL" pipeline between a Postgres database and a data warehouse or lakehouse
• A read replica dedicated to analytics queries
• Separate governance policies for your operational and analytical data
• AI agents that need to read fresh transactional data to make decisions

LTAP is coming soon as a part of Lakebase. No separate pricing has been announced. Lakebase and LTAP are the infrastructure bets to watch for the next 12 to 18 months. The architecture is technically sound and the Lakebase foundation is already in production at scale , but LTAP has to demonstrate that this elegant architecture survives contact with messy enterprise workloads. If it does, the two-system data stack that has defined enterprise infrastructure for four decades may finally have a credible replacement.