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)
There is controversy in the industry over whether "one database can do both transactions and analytics well at the same time": opponents argue that the physical-level requirements differ too greatly and a unified architecture will inevitably compromise on one end; proponents argue that modern hardware and new technologies have already blurred the physical boundaries.
Early HTAP solutions mostly adopted compromise approaches of "stitching two engines together" or "in-memory row store plus disk columnar store replica," often conceding on freshness, consistency, or the performance of one side.
To judge whether a system counts as truly HTAP, one usually looks at whether it can achieve near-real-time consistency between analytical results and transactional writes on the same copy of data, without relying on additional ETL synchronization.
The concept of HTAP (Hybrid Transactional/Analytical Processing) was formally proposed by Gartner around 2014, referring to using a single system to carry both OLTP and OLAP workloads simultaneously.
Representative HTAP implementations include TiDB, OceanBase and SingleStore, among others, and the core idea is to use the same storage with different execution engines to serve transactional and analytical queries respectively.
HTAP (Hybrid Transactional/Analytical Processing) is a database architecture concept that attempts to support both high-concurrency transaction processing and analytical queries in a single system.
In HTAP scenarios, MVCC's version chain and visibility determination mechanism allow analytical queries to read the latest committed data version without stopping transactional writes, thereby eliminating read-write conflicts and avoiding ETL synchronization latency.
HTAP systems usually place hot data in memory to balance performance.
HTAP systems face the engineering challenge of resource isolation versus performance trade-offs: large aggregation queries may saturate CPU and memory, slowing down critical transaction writes, while resource isolation itself may sacrifice efficiency.
HTAP is more suitable for medium-scale analytical scenarios with high real-time requirements; for ultra-large-scale data warehouse workloads or core financial systems with extremely high requirements for transactional consistency, traditional architectures may still be the more prudent choice.
11 more timeline events
All Facts (20)
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.
70%UnverifiedThere is controversy in the industry over whether "one database can do both transactions and analytics well at the same time": opponents argue that the physical-level requirements differ too greatly and a unified architecture will inevitably compromise on one end; proponents argue that modern hardware and new technologies have already blurred the physical boundaries.
50%UnverifiedEarly HTAP solutions mostly adopted compromise approaches of "stitching two engines together" or "in-memory row store plus disk columnar store replica," often conceding on freshness, consistency, or the performance of one side.
50%UnverifiedTo judge whether a system counts as truly HTAP, one usually looks at whether it can achieve near-real-time consistency between analytical results and transactional writes on the same copy of data, without relying on additional ETL synchronization.
50%UnverifiedThe concept of HTAP (Hybrid Transactional/Analytical Processing) was formally proposed by Gartner around 2014, referring to using a single system to carry both OLTP and OLAP workloads simultaneously.
50%UnverifiedRepresentative HTAP implementations include TiDB, OceanBase and SingleStore, among others, and the core idea is to use the same storage with different execution engines to serve transactional and analytical queries respectively.
50%UnverifiedHTAP (Hybrid Transactional/Analytical Processing) is a database architecture concept that attempts to support both high-concurrency transaction processing and analytical queries in a single system.
50%UnverifiedIn HTAP scenarios, MVCC's version chain and visibility determination mechanism allow analytical queries to read the latest committed data version without stopping transactional writes, thereby eliminating read-write conflicts and avoiding ETL synchronization latency.
50%UnverifiedHTAP systems usually place hot data in memory to balance performance.
50%UnverifiedHTAP systems face the engineering challenge of resource isolation versus performance trade-offs: large aggregation queries may saturate CPU and memory, slowing down critical transaction writes, while resource isolation itself may sacrifice efficiency.
50%UnverifiedHTAP is more suitable for medium-scale analytical scenarios with high real-time requirements; for ultra-large-scale data warehouse workloads or core financial systems with extremely high requirements for transactional consistency, traditional architectures may still be the more prudent choice.
50%UnverifiedWhen selecting HTAP, it is recommended to pay attention to whether analytical query latency meets business requirements, whether transactional throughput is stable under high load, and whether operational complexity is within the team's affordable range.
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%UnverifiedRepresentative products of HTAP include TiDB and SingleStore.
50%UnverifiedThe HTAP concept was proposed by Gartner as early as around 2014.
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%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%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%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%UnverifiedAlthough HTAP (Hybrid Transactional/Analytical Processing) has been proposed for many years, most systems still internally maintain two separate storage engines.
50%