Lake Transactional/Analytical Processing (LTAP)
Lake Transactional/Analytical Processing (LTAP) is a Databricks data engineering capability, introduced June 2026.
An architecture, not a feature: one storage layer in the lake that serves both transactional (OLTP) and analytical (OLAP) workloads under a single governance model, removing the CDC, replication, and transformation pipelines teams otherwise run to copy operational data into a separate analytical system. You implement it by combining Lakebase capabilities per dataset: Lakehouse Real-Time or Lakebase Change Data Feed when Lakebase owns the write, synced tables (optionally with LTAP Direct Writes) when the lakehouse does, and registering the database in Unity Catalog for governance.
- 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-10-14