LTAP
LTAP (Live Transactional-Analytical Processing) is an emerging database architecture paradigm designed to unify OLTP and OLAP workloads, eliminating the traditional ETL intermediate layer. It enables data written to be immediately available for analysis and is particularly suited to the mixed real-time workload patterns associated with AI agents.
Core Facts
Timeline (last 90 days)
LTAP allows transactional processing and analytical processing to read from the same copy of data.
Databricks has chosen to use Postgres as the foundation and bridge transactions and analytics through LTAP.
In the LTAP architecture, the underlying storage is typically based on object storage in open formats (such as Delta Lake), rather than traditional row-store or column-store engines.
LTAP is an extension and upgrade of the traditional HTAP concept, with the difference being that it places this capability within the context of a lakehouse architecture.
The full name of LTAP is Lakehouse Transaction and Analytics Processing.
The core difference between LTAP and HTAP lies in the shift of focus from engine convergence to storage layer unification, with LTAP acknowledging the irreplaceability of dedicated engines in their respective domains.
LTAP adopts a tiered storage design: hotter tiers store data in row format to serve operational access, while colder tiers store the same data in columnar format to serve analytical reads.
In LTAP, dedicated compute engines can independently handle their respective workloads—row-based engines handle transactions and columnar engines handle analytics—with data flowing between the two tiers according to access temperature.
Maintaining data consistency between hot and cold tiers in the LTAP architecture introduces additional complexity, which is the cost of its trade-offs.
If LTAP matures and is widely adopted, the most direct benefit is a significant reduction in data freshness latency, allowing the analytics side to read near-real-time operational data without the operational side needing to yield to analytical queries.
7 more timeline events
All Facts (18)
Databricks implemented the data Lakehouse architecture through its open-source project Delta Lake.
90%UnverifiedLTAP is a new architectural paradigm aimed at unifying OLTP and OLAP workloads, enabling the same system to handle both transactions and analytics with high performance simultaneously.
70%UnverifiedDatabricks has chosen to use Postgres as the foundation and bridge transactions and analytics through LTAP.
50%UnverifiedLTAP allows transactional processing and analytical processing to read from the same copy of data.
50%UnverifiedThe full name of LTAP is Lakehouse Transaction and Analytics Processing.
50%UnverifiedLTAP is an extension and upgrade of the traditional HTAP concept, with the difference being that it places this capability within the context of a lakehouse architecture.
50%UnverifiedIn the LTAP architecture, the underlying storage is typically based on object storage in open formats (such as Delta Lake), rather than traditional row-store or column-store engines.
50%UnverifiedLTAP adopts a tiered storage design: hotter tiers store data in row format to serve operational access, while colder tiers store the same data in columnar format to serve analytical reads.
50%UnverifiedIn LTAP, dedicated compute engines can independently handle their respective workloads—row-based engines handle transactions and columnar engines handle analytics—with data flowing between the two tiers according to access temperature.
50%UnverifiedThe core difference between LTAP and HTAP lies in the shift of focus from engine convergence to storage layer unification, with LTAP acknowledging the irreplaceability of dedicated engines in their respective domains.
50%UnverifiedMaintaining data consistency between hot and cold tiers in the LTAP architecture introduces additional complexity, which is the cost of its trade-offs.
50%UnverifiedAs an architectural concept still evolving, LTAP needs to address engineering challenges such as hot-cold tier data migration strategies and cross-tier query consistency guarantees during implementation.
50%UnverifiedLTAP (Lakehouse Transactional-Analytical Processing) is a lakehouse-oriented extension of the HTAP concept, combining the idea of transactional-analytical processing with open table formats such as Delta Lake.
50%UnverifiedLTAP allows the underlying engine to dynamically adapt based on access patterns, making data available for analysis immediately after it is written, without the need for migration or transformation.
50%UnverifiedLTAP attempts to eliminate the ETL intermediate step, putting transactional data into an analyzable state the moment it is generated.
50%UnverifiedEliminating ETL latency may be the decisive differentiator in scenarios such as financial risk control, real-time recommendations, and automated operations.
50%UnverifiedWhether LTAP can truly achieve a single system that handles both types of workloads remains to be verified in practice, and long-standing HTAP challenges such as storage format trade-offs, resource isolation, and query optimization complexity still exist.
50%UnverifiedIf LTAP matures and is widely adopted, the most direct benefit is a significant reduction in data freshness latency, allowing the analytics side to read near-real-time operational data without the operational side needing to yield to analytical queries.
50%