HTAP
Hybrid Transactional/Analytical Processing (HTAP) is a database architecture concept that aims to support both transactional (OLTP) and analytical (OLAP) workloads within a single system. Most implementations still maintain two separate storage engines internally to serve each workload type.
Timeline (last 90 days)
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.
Representative products of HTAP include TiDB and SingleStore.
The HTAP concept was proposed by Gartner as early as around 2014.
HTAP (Hybrid Transactional/Analytical Processing) aims to build a single engine capable of handling both types of workloads simultaneously, supporting both access modes by maintaining dual data replicas—row store and column store—within the same system.
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 (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.
Traditional HTAP systems achieve parallel transactional and analytical processing by maintaining two data copies—row-store and column-store—within the same database engine; Oracle, TiDB, and SingleStore all adopt this approach.
Although HTAP (Hybrid Transactional/Analytical Processing) has been proposed for many years, most systems still internally maintain two separate storage engines.
Whether 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.
New-generation databases such as TiDB and CockroachDB attempt to simultaneously support both OLAP and OLTP workloads within a single system (HTAP).
All Facts (10)
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.
50%UnverifiedRepresentative products of HTAP include TiDB and SingleStore.
50%UnverifiedThe HTAP concept was proposed by Gartner as early as around 2014.
50%UnverifiedHTAP (Hybrid Transactional/Analytical Processing) aims to build a single engine capable of handling both types of workloads simultaneously, supporting both access modes by maintaining dual data replicas—row store and column store—within the same system.
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%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%UnverifiedTraditional HTAP systems achieve parallel transactional and analytical processing by maintaining two data copies—row-store and column-store—within the same database engine; Oracle, TiDB, and SingleStore all adopt this approach.
50%UnverifiedAlthough HTAP (Hybrid Transactional/Analytical Processing) has been proposed for many years, most systems still internally maintain two separate storage engines.
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%UnverifiedNew-generation databases such as TiDB and CockroachDB attempt to simultaneously support both OLAP and OLTP workloads within a single system (HTAP).
50%