Lake Transactional/Analytical Processing (LTAP)
Lake Transactional/Analytical Processing (LTAP) is a Databricks data engineering capability, introduced June 2026.
A data processing architecture that unifies transactional (OLTP) and analytical (OLAP) workloads on a single copy of data in the lake, combining Lakebase (serverless Postgres on open object storage) with the Lakehouse under one governance model - so operational and analytical apps share one source of truth without ETL, replicas, or pipelines. Announced June 2026 and, per the press release's own availability note, coming soon as part of Lakebase.
- Databricks declared itself the world's first LTAP platform on the same day it coined the term LTAP, which does make the claim hard to dispute.
- The name is a deliberate play on HTAP, the decades-old holy grail of one engine doing both jobs; LTAP gives up on that and keeps Postgres for the writes and Lakehouse engines for the reads, unifying only the storage underneath.
- The architecture whose whole pitch is that there is no second copy of your data currently keeps two: during the transitional rollout Databricks dual-writes row and columnar formats to object storage, purely to check its own arithmetic.
Limitations: Not shipped yet: Databricks says it is still ironing out the kinks and rolling it out 'in the coming months', during which it dual-writes row and columnar copies of the data purely to verify itself. Very small tables are left unconverted rather than given Iceberg metadata (they stay queryable), and the intermediate Postgres row versions kept for MVCC and point-in-time recovery are not visible to Iceberg or Delta readers.
Open in REbricked →- Category
- Data engineering
- Also known as
- LTAP
- Verified
- 2026-08-04