Lake Transactional/Analytical Processing (LTAP)
Lake Transactional/Analytical Processing (LTAP) is a Databricks data engineering capability, introduced June 2026.
A data architecture that serves both transactional (OLTP) and analytical (OLAP) workloads from one unified storage layer in the lake under a single governance model, removing the CDC, replication, and transformation pipelines teams otherwise maintain to copy operational data into a separate analytical system. Databricks builds it on the Lakebase storage architecture and ships it as a set of Lakebase capabilities rather than as one feature.
- 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 spent its rollout keeping two: Databricks dual-writes row and columnar formats to object storage during the transitional rollout stage, purely to check its own arithmetic.
Limitations: Unity Catalog governs only analytical access to registered Lakebase data, not individual Postgres tables, so the transactional path is still controlled by Postgres GRANT and REVOKE. Each table has a single writer, either Lakebase or the lakehouse, and the capabilities implementing LTAP sit at mixed maturity and vary by cloud: registering Lakebase in Unity Catalog and synced tables are GA, LTAP Direct Writes and Lakehouse//RT queries on Lakebase are Beta, and Lakebase Change Data Feed is in Public Preview.
Open in REbricked →- Category
- Data engineering
- Also known as
- LTAP
- Verified
- 2026-08-20