12 million database launches per day across thousands of customers - that's the base Databricks is using to sell their new LTAP (Lake Transactional/Analytical Processing) architecture. If the numbers hold, this is the most credible attempt yet to kill the decades-old separation between operational databases and analytical warehouses.
The Old Tradeoff: Separate Systems or Messy HTAP
For forty years, transactional and analytical workloads lived in different houses. Operational databases handled writes and low-latency queries; analytical engines chewed on large scans and aggregations. The bridge between them was CDC pipelines - brittle, latency-prone, and expensive to maintain. HTAP tried to force both workloads into the same engine and collapsed workload isolation, sacrificing performance for both. Zero ETL just hid the pipeline rather than removing it. LTAP takes a different bet: unify at the storage layer, not the engine.
Databricks stores all operational data in Lakebase (serverless Postgres on object storage) and all analytical data in the Lakehouse, but now both live on the same copy of data in Unity Catalog using open formats like Delta and Iceberg. No data movement. No hidden pipelines. Just a single governed surface that agents and applications can read and act on without delay.
Lakebase: 12 Million Launches and Counting
Lakebase launched only last year and already serves Block, Ensemble, Superhuman, and Zillow. 12 million database launches per day is a real stress test for any serverless Postgres offering. Databricks added cross-cloud disaster recovery, git-style branching with snapshots, and autonomous database operations - agents that monitor health, detect slowdowns, and propose indexes. These features target the agentic era where AI generates 50x more applications than human developers alone.
How LTAP Completes the Architecture
The key claim: transactional and analytical workloads scale independently with full isolation, but because there's no data movement, results are always in sync. LTAP gives you standard Postgres ACID semantics for OLTP and the full Lakehouse engine for analytics. One governance model, one set of permissions, one copy of data. No replicas, no shadow infrastructure, no ETL tax.
Ali Ghodsi didn't mince words: “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.” LTAP is Databricks' answer to that bottleneck. Whether it delivers on the promise of independent scaling without storage-layer contention remains to be seen, but the engineering bet is clear: object storage is fast enough, Postgres is good enough, and Unity Catalog is the binding that makes it all governable.
LTAP will be tested by enterprises that need agents to act on fresh data in seconds, not minutes. If the performance numbers from early customers hold up, this architecture could retire more data pipelines than any single announcement in the last decade.
Source: Databricks Launches LTAP: A Unified OLAP/OLTP Data Architecture
Domain: databricks.com
Comments load interactively on the live page.