What is HTAP? A plain-English guide to hybrid transactional/analytical processing

What is HTAP? A plain-English guide to hybrid transactional/analytical processing | Databricks Blog Skip to main content

Consider a payment system processing a purchase. Before approving the transaction, a fraud model may need to evaluate it against the account's recent activity. But if that transactional data must first move from the transactional database to a data warehouse for analysis, even a short delay can make the result less useful. Hybrid Transactional/Analytical Processing (HTAP) brings transaction processing and analytics closer together to address this problem. An HTAP database lets you run analytical queries on operational data while it is still current, without waiting for a batch data pipeline to move it into a separate analytical system. In this guide, you'll learn how HTAP works, the architectural tradeoffs involved, and where it fits in a modern data architecture. You'll also see how different HTAP systems approach transactional and analytical workloads, how HTAP compares with Lake Transactional/Analytical Processing (LTAP), and what to consider when evaluating and adopting either approach. TL;DR HTAP brings transactional and analytical processing closer together so applications can run analytics on fresh transactional data. Different HTAP architectures involve different trade-offs in performance, isolation, data consistency, and freshness. Choose the architecture based on your workload. LTAP provides greater separation between transactional and analytical compute while both operate on the same data.

What is HTAP? HTAP stands for Hybrid Transactional/Analytical Processing. Gartner coined the term in 2014 to describe architectures that bring online transaction processing (OLTP) and online analytical processing (OLAP) together within an integrated database system. Gartner's original framing of hybrid transaction/analytical processing argued that combining the two would create opportunities for dramatic business innovation, because decisions could be OLTP handles high volumes of small, frequent transactional operations that keep applications running, such as creating an order, processing a payment, or updating an account. OLAP processes complex queries over large datasets to calculate metrics, identify patterns, and answer analytical questions.made on the latest transactions rather than on yesterday's extract.

HTAP brings these workloads closer together, giving analytical queries access to current operational data without depending entirely on a separate batch ETL pipeline. For many operational analytics use cases, HTAP systems can reduce or remove the need for ETL processes, cut down the number of data copies teams maintain, and move closer to a single source of truth for both operational and analytical systems. In the most integrated designs, OLTP and OLAP capabilities live in a single system rather than in two products stitched together. Bringing OLTP and OLAP workloads closer together does not mean they have to run in exactly the same way. HTAP architectures therefore differ in how they combine OLTP and OLAP capabilities while preserving the characteristics each workload needs. Two common approaches are: Converged HTAP: Runs transactional and analytical workloads through a single database engine. The workloads may use different indexes, storage formats, or execution paths, but they share much of the same database. Composed HTAP: Uses separate transactional and analytical engines within an integrated architecture. The engines may share a storage layer or propagate changes through replication while remaining optimized for their respective workloads.

A converged engine avoids the need to synchronize independent query engines, but it must prevent analytical operations from interfering with latency-sensitive transactions. A composed architecture provides greater freedom to optimize and isolate each workload, but it must coordinate data versions and keep the analytical path sufficiently fresh. In both cases, the central HTAP challenge is the same: provide analytical access to operational data quickly enough to be useful without compromising the performance and reliability of transactional workloads. Why OLTP and OLAP became separate systems OLTP and OLAP have different access patterns. Transactional queries typically read or update a small number of complete rows. OLTP databases therefore rely on row-based storage, selective indexes, efficient concurrency control, and predictable latency, often measured in milliseconds. Most transactional databases are relational databases tuned to keep that latency low even under heavy concurrency. Analytical queries, by contrast, often scan millions of rows across a subset of columns to calculate metrics or identify patterns. OLAP databases use columnar storage because a column store improves compression and reduces the amount of unnecessary data read during large scans and aggregations. OLAP systems can tolerate longer latency for complex queries, trading seconds of response time for the ability to analyze far more data. Optimizing OLTP and OLAP systems separately therefore made practical sense, but it introduced a new problem: the delay caused by data movement between them. Operational data typically had to be copied out of the OLTP system and into a data warehouse or other analytical database before it could be analyzed. Transactions and analytics processing ran on different schedules, on different hardware, against different copies of the data. Traditional architectures that separate OLTP and OLAP systems in this way build latency into every analytical answer. As requirements for fresher data grew, data teams started assembling their own custom systems to close the gap. Change data capture feeds, stream processors, cloud data warehouses, cloud data lakes, and real-time query layers became the building blocks of today's disaggregated data stack. Each component solved a specific problem, but every additional hop added cost, operational effort, and another place where data consistency could break. HTAP addresses that delay while preserving the performance benefits of workload-specific optimization. How HTAP architecture works An HTAP architecture provides paths for both transactional and analytical workloads while keeping operational data available for analysis with minimal delay. The exact design varies by system, but the architecture generally includes transaction processing, analytical...