HTAP (Hybrid Transactional/Analytical Processing) is a database architecture that handles both transactional (OLTP) and analytical (OLAP) workloads within a single system. Rather than maintaining separate operational and analytical databases connected by ETL pipelines, an HTAP system processes write-heavy transactional operations and complex analytical queries against the same underlying data store, in real time.
The term was coined by Gartner in 2014, initially in the context of in-memory databases. Gartner later extended the concept in 2018 to cover systems that weave transactional and analytical processing techniques together as needed, not necessarily restricted to in-memory architectures.
The Problem HTAP Was Designed to Solve
The traditional architecture for combining operational and analytical data looks like this: an OLTP database (PostgreSQL, MySQL, Oracle) handles application transactions; periodically, an ETL process extracts that data, transforms it, and loads it into a data warehouse or OLAP system (Redshift, Snowflake, BigQuery) where analysts run reports. This works, but it has a fundamental limitation: your analytics are always behind your operational data by hours or days, depending on how frequently ETL runs.
This lag matters in contexts where decisions need to be made on current data:
- Fraud detection: A transaction that looks suspicious needs to be evaluated against recent transaction history, not yesterday's snapshot.
- Real-time personalization: A recommendation engine needs to know what a user clicked on two minutes ago, not what they clicked on last night.
- Operational reporting: A business dashboard showing live order throughput or active sessions needs to reflect the current state, not a stale export.
The traditional answer to these requirements was to query the operational OLTP database directly for analytics, which either degraded transactional performance or required careful read replica setup - and still left you with a system not designed for complex aggregations over large datasets.
HTAP emerged as a proposed solution: eliminate the ETL entirely and run both workload types in the same system against the same data.
How HTAP Databases Work
Most HTAP databases use a dual-storage model internally: a row-oriented store optimized for transactional point reads and writes, and a columnar store optimized for analytical scan-and-aggregate queries. The system maintains both representations simultaneously and synchronizes changes between them, typically in near real time.
When a transaction commits to the row store, changes are propagated to the columnar store asynchronously (with a small, bounded lag - often milliseconds to seconds). The query optimizer then routes incoming queries to the appropriate store: transactional point lookups go to the row store, analytical aggregations go to the columnar store. Some systems allow a single query to span both stores, joining fresh transactional data with pre-aggregated analytical results.
TiDB (by PingCAP) is one of the most prominent examples. It uses TiKV as the row store for OLTP workloads and TiFlash as a columnar replica for OLAP. Changes replicate from TiKV to TiFlash via the Raft consensus protocol, making TiFlash always consistent with recent transactions. The MySQL-compatible SQL layer routes queries to the appropriate engine automatically, or allows explicit per-query hints.
Other systems that have shipped HTAP capabilities include:
- SingleStore (formerly MemSQL): an in-memory row store with an on-disk columnar store per table, automatically synced
- AlloyDB (Google): a PostgreSQL-compatible system with a disaggregated columnar engine for analytical scans
- Oracle Database: long supported mixed workloads via In-Memory Column Store, an optional in-memory columnar representation kept synchronized with the on-disk row store
Use Cases
HTAP architecture made the most sense when data freshness was genuinely critical and the engineering team could not tolerate even minutes of lag between an event occurring and being queryable in analytics.
Concrete scenarios where HTAP was adopted:
- Financial services: Real-time fraud scoring that needs to compare a current transaction against a live window of account activity
- E-commerce: Inventory checks and recommendation queries that need to reflect current stock and recent browsing behavior simultaneously
- Telecommunications: Network anomaly detection that queries streaming event data as it arrives, against aggregated baseline patterns
- Gaming and ad tech: Sub-second leaderboard updates and impression counting that need to be both accurate and current
The Operational Complexity Problem
In practice, HTAP systems introduce significant operational challenges that the marketing often understates.
Resource contention is the central problem. Transactional workloads and analytical workloads have fundamentally different resource profiles. OLTP is latency-sensitive and favors low memory footprint per query, high concurrency, and fast disk writes. OLAP is throughput-sensitive and favors full CPU utilization, large memory buffers for aggregations, and sequential disk reads. Running both on shared hardware means that a heavy analytical query competes directly with transactional latency. HTAP systems mitigate this through resource isolation (separate thread pools, query scheduling priorities, sometimes separate node groups), but contention cannot be fully eliminated - only managed.
Schema design is another tension. Optimal schema for OLTP (normalized tables, foreign keys, frequent point updates) is the opposite of optimal for OLAP (wide denormalized tables, append-only inserts, pre-aggregated structures). An HTAP system forces you to design a single schema that is acceptable for both, which typically means suboptimal performance on both ends.
Synchronization lag and consistency guarantees also require careful thought. The column store replica is never perfectly in sync with the row store. Queries that span both engines, or that require reading your own writes from the analytical engine, need explicit handling. The synchronization subsystem adds failure modes and recovery complexity that do not exist in a separated architecture.
Cost and operational overhead scale with the dual-storage model. You are effectively running two storage engines per table, plus the synchronization machinery. This increases both hardware costs and the surface area for things to go wrong.
The Modern Alternative: Dedicated OLTP + CDC + Dedicated OLAP
The promise of HTAP - eliminating ETL lag and enabling real-time analytics on live operational data - is legitimate. But the approach of building one system to do both has largely been superseded by a cleaner architecture: dedicated OLTP database → Change Data Capture → dedicated OLAP database.
The key shift is that CDC-based replication has matured dramatically. Tools like Debezium, Airbyte, and cloud-native CDC services from AWS (DMS), Google (Datastream), and Azure capture every row-level change from a database's transaction log and stream it to a downstream system in near real time - typically with sub-second lag. Apache Kafka serves as the durable event bus between systems in the majority of production deployments.
This approach gives you:
- Best-in-class OLTP: PostgreSQL, MySQL, or your database of choice, tuned and operated purely for transactional workloads, without any OLAP overhead
- Best-in-class OLAP: ClickHouse, BigQuery, Snowflake, or another columnar system, tuned and operated purely for analytical workloads, with storage formats and indexes optimized for aggregation
- Data freshness measured in seconds, not hours - comfortably fast enough for fraud detection, operational dashboards, and most real-time analytics use cases
- Independent scaling: scale your transactional database and your analytical database separately, based on their individual load profiles
- No resource contention: a heavy analytical query on ClickHouse has no effect on transaction latency on PostgreSQL
- Schema freedom: design your OLTP schema for your application's access patterns, and design your OLAP schema for query performance - they can be completely different
- Simpler failure modes: if the analytical system has an incident, transactional workloads are unaffected, and vice versa
The overhead of operating two systems is real, but the tooling has reduced it substantially. Managed CDC services and hosted OLAP databases mean that a two-person engineering team can operate a production pipeline with sub-second replication lag and petabyte-scale analytics, without deep expertise in the internals of either system.
HTAP made sense when the tooling for CDC and managed OLAP was immature and the engineering cost of operating two specialized systems was prohibitively high. Today, that cost has fallen far enough that the tradeoffs look different. For most teams, maintaining a clean replication pipeline from a dedicated OLTP system to a dedicated OLAP system will outperform any HTAP architecture - in query performance, operational reliability, and engineering flexibility - while keeping each system optimized for exactly what it is designed to do.
