Running transactional and analytical workloads on separate systems means every dashboard, fraud check, or inventory report is working from data that is minutes, hours, or a full ETL cycle out of date. An HTAP database, short for Hybrid Transactional and Analytical Processing, runs both OLTP and OLAP directly against the same live data, in the same engine, without a pipeline in between. Gartner coined the term in 2014 to describe exactly this pattern. 티DB is one of the databases built around it, using two storage engines, TiKV and TiFlash, kept in sync through Raft-based replication instead of a batch ETL job.
Definition and Fundamental Concepts of HTAP
Hybrid Transactional and Analytical Processing (HTAP) represents a significant shift in database architecture, designed to handle both transactional (OLTP) and analytical (OLAP) workloads within a single system. Traditionally, OLTP systems manage real-time transactional data, while OLAP systems are used for analytical queries that involve large datasets. HTAP bridges this gap, allowing users to perform complex queries on fresh transactional data without the need for data replication or synchronization delays.
Historical Challenges in Combining OLTP and OLAP
Combining OLTP and OLAP functionalities has historically presented numerous challenges. Traditional databases often had to be split into separate systems: one optimized for transactional jobs and another for analytical tasks. This separation led to several issues:
- Data Latency: Real-time analytics were hindered by the need to transfer data from OLTP systems to OLAP systems.
- Consistency Issues: Maintaining data consistency across multiple platforms was complex and error-prone.
- Operational Overhead: Managing, maintaining, and synchronizing two distinct systems added significant overhead.
Technological Advances Enabling HTAP Solutions
Technological advancements have made HTAP solutions viable, addressing the aforementioned challenges. Key innovations include:
- In-Memory Computing: The advent of in-memory databases allows for rapid data retrieval and processing.
- Columnar Storage: This storage format optimizes read-heavy analytical queries, complementing traditional row-based storage used in OLTP.
- Distributed Systems: Modern distributed databases enable scalable and fault-tolerant solutions that can handle vast amounts of data simultaneously for both transactional and analytical workloads.
- Sophisticated Query Optimizers: Advances in query optimization ensure efficient and cost-effective processing of complex queries across hybrid workloads.
Why Some Vendors Are Moving Away From HTAP
Not every database vendor still believes in a single engine for both workloads. A widely read guide from ClickHouse argues that OLTP and OLAP have fundamentally different storage, I/O, and concurrency requirements, and that no single engine serves both without compromise. Its position: pair a dedicated OLTP engine with a dedicated OLAP engine, connected by change data capture (CDC) and zero-ETL replication, instead of forcing one engine to do both jobs.
That trade-off is real. Two purpose-built engines can each be tuned harder for their one job, and modern CDC tools have closed much of the latency gap that used to justify HTAP. Where the composable argument breaks down is data consistency: a CDC pipeline is still a pipeline, with its own lag, schema-drift risk, and failure modes to monitor. An HTAP database removes that pipeline entirely, at the cost of running one engine tuned for two different access patterns. Which trade-off wins depends on how fresh the analytical answer needs to be, and how much operational surface area a team wants to own.
How TiDB Solves the OLTP/OLAP Split
TiDB answers the freshness question directly with two storage engines instead of one shared engine. TiKV is a row-based store built for OLTP: fast point reads, writes, and short transactions. TiFlash is a columnar store built for OLAP: it scans and aggregates efficiently across large ranges of rows. A single SQL layer sits in front of both and routes each query to whichever engine fits it.
The two engines stay in sync through the Multi-Raft Learner protocol: TiFlash replicates data from TiKV as a learner in the same Raft group, so analytical queries read data that reflects committed transactions without a separate ETL job moving it there. Adding a columnar replica to an existing table takes one statement:
ALTER TABLE my_table SET TIFLASH REPLICA 1;In one documented case, a team running a 100+ line analytical query with multiple joins and a SUM aggregate against TiKV alone saw it take minutes to complete; the same query against a TiFlash replica of the same table finished in 50 seconds, with results guaranteed consistent with the source data by Raft. That is the mechanism-level answer to the composable-architecture argument: TiDB isn’t asking one engine to do two jobs badly, it is running two engines that share a replication protocol instead of a pipeline.
When an HTAP Database Makes Sense vs. When It Doesn’t
An HTAP database is the better fit when the analytical answer needs to reflect transactions from seconds ago: live fraud checks, operational dashboards, or inventory counts that drive an immediate decision. Rakuten rebuilt its loyalty program on TiDB for exactly this reason, moving off a setup where transactional and analytical data lived apart and syncing them was the bottleneck.
A composable, CDC-based setup can still make sense when the two workloads have very different scaling needs, for example petabyte-scale batch analytics that would never share hardware economics with a transactional cluster, and a few minutes of replication lag is genuinely acceptable. The deciding question isn’t which architecture is newer, it’s how much lag the business can tolerate before a stale answer becomes a wrong one.
자주 묻는 질문
What is the difference between HTAP and OLAP?
- OLAP describes analytical workloads on their own: complex, read-heavy queries over large datasets, usually run in a data warehouse.
- HTAP describes a database that runs OLAP-style analytical queries and OLTP-style transactional queries in the same system.
- An OLAP-only system typically depends on an ETL or CDC pipeline to receive data from a separate transactional source.
- An HTAP database removes that pipeline by keeping both workloads on data that shares a single source of truth.
Is TiDB an HTAP database?
- Yes. TiDB pairs TiKV, a row-based OLTP engine, with TiFlash, a columnar OLAP engine.
- The two engines are kept in sync through the Multi-Raft Learner protocol rather than a batch job.
- A single SQL layer routes OLTP and OLAP queries to whichever engine fits.
- TiFlash replicas can be added per table with one ALTER TABLE statement.
Does HTAP replace a data warehouse?
- Not for every workload. HTAP is built for queries that need fresh, current-state data.
- A data warehouse is still the better fit for petabyte-scale historical analysis with a longer acceptable lag.
- Some teams run both: TiDB for real-time operational analytics, a warehouse for deep historical reporting.
- The two aren’t mutually exclusive; TiDB integrates with tools like TiSpark for exactly this kind of split workload.
Get Real-Time Answers Without Building a Pipeline
An HTAP database doesn’t win every workload, but it removes an entire category of pipeline failure for the ones where freshness matters most. TiDB’s TiKV and TiFlash engines, kept in sync through Raft rather than CDC, are built for exactly that case. Try TiDB Cloud Serverless free to run both workloads against the same live data with no separate ETL pipeline to build or babysit.