Key Takeaways
- NoSQL traded consistency for scale. HTAP keeps both and adds real-time analytics on the same data.
- TiDB runs OLTP on TiKV, a row store, and OLAP on TiFlash, a column store, inside one cluster with one SQL interface.
- TiFlash replicates from TiKV as a Raft learner, and its reads stay consistent even though replication is asynchronous.
- Trip.com replaced a T+1 pipeline into Elasticsearch with a billion-record customer data platform on TiDB.
A team running separate OLTP and OLAP systems pays for it twice: once in ETL pipeline maintenance, and again in the lag between a transaction happening and that transaction showing up in a report. Hybrid transactional and analytical processing (HTAP) removes that split. TiDB, PingCAP’s open-source distributed SQL database, implements HTAP through two purpose-built storage engines running on the same cluster, so analytical queries run against live transactional data instead of a stale copy.
What is HTAP, and How Does TiDB Implement It?
HTAP is a database architecture that handles both transactional (OLTP) and analytical (OLAP) workloads in a single system, instead of splitting them across two databases connected by an ETL pipeline. TiDB implements HTAP with two engines on one cluster: TiKV, a row-based store, handles transactional reads and writes, while TiFlash, a columnar store, handles analytical queries.
TiFlash replicates data from TiKV as a Raft learner: it receives every write TiKV commits without taking part in leader election or voting. Replication runs asynchronously, so it adds no latency to transactional writes. Reads stay consistent anyway. Before answering a query, a TiFlash replica checks with the Region’s Raft leader and waits until it has applied every write up to the query’s timestamp, so an analytical query sees the same consistent snapshot TiKV would serve.
How NoSQL Got Here
NoSQL databases emerged in the mid-2000s, after Google’s Bigtable paper (2006) and Amazon’s Dynamo paper (2007) showed how to scale past what a single relational database could handle. The tradeoff at the time was deliberate: give up strong consistency and SQL’s query model in exchange for horizontal scale and schema flexibility.
That tradeoff made sense when scale was the primary constraint. It matters less today, when workloads including AI agent memory and RAG pipelines need both the scale NoSQL provided and the transactional consistency it gave up to get there. HTAP databases like TiDB answer that shift directly: horizontal scale without sacrificing ACID guarantees, plus analytics on the same live data. For the broader NewSQL story, the tradeoff between distributed scale and consistency, see NewSQL Databases: Scalability Meets Consistency in 2026. This page focuses on the HTAP half.
How TiDB’s HTAP Architecture Works
TiKV stores data in Regions, each replicated across nodes through Raft consensus for fault tolerance. TiFlash attaches to that same replication stream as a learner: every committed write to TiKV reaches TiFlash automatically, converted from row format into columnar storage built for scan-heavy analytical queries.
TiDB uses MVCC (multi-version concurrency control) so analytical queries read a consistent snapshot without blocking concurrent transactional writes. Reads and writes proceed on separate timelines that never lock each other out, which is what lets a long-running analytical scan and a burst of transactional writes share a cluster without one degrading the other.
TiDB’s optimizer decides per query whether to read from TiKV or TiFlash, based on cost. Within a single statement, different tables can even read from different engines: an index lookup on TiKV for one table, a columnar scan on TiFlash for another. The application never picks an engine. It sends one SQL statement, and the transactional insert and the analytical aggregate both run against the same table on the same cluster, with no second system to maintain.
TiDB HTAP in Production: Trip.com’s Customer Data Platform
Trip.com, the travel platform behind Trip.com, Qunar, and Skyscanner with more than 90 million members, built a real-time tagging customer data platform (CDP) on TiDB. Before TiDB, a data warehouse calculated tags T+1, and a separate job imported them into an Elasticsearch cluster for querying. With more than a hundred tags deployed and over half of them used for queries, every result ran at least a day behind the business.
On TiDB, incremental changes stream through Kafka or QMQ message queues and write to TiDB as they happen. TiKV serves the transactional lookups and TiFlash serves the analytical queries, and TiDB keeps the two engines in sync, so queries against roughly a billion records run on current data in one system. Historical data still backfills through Spark batch jobs. What HTAP removed is the lag for everything that happens after the backfill, which is the part the business actually queries.
For Trip.com’s hotel settlement workload, which tests the consistency side of the same architecture, see NewSQL Databases: Scalability Meets Consistency in 2026.
Start Building on TiDB’s HTAP Architecture
HTAP closes the gap NoSQL’s early tradeoffs opened between scale and consistency, and adds real-time analytics on top. TiDB’s TiKV and TiFlash design delivers that in production at billion-record scale for Trip.com.
Try TiDB Cloud Starter free to run your own OLTP and OLAP workloads on one cluster.
TiDB HTAP FAQs
What does HTAP stand for?
- HTAP stands for Hybrid Transactional and Analytical Processing.
- It describes a database that runs OLTP and OLAP workloads on the same system.
- It removes the need for a separate ETL pipeline between the two.
- TiDB implements this model natively.
How is TiDB’s HTAP different from a standard OLTP/OLAP split?
- A standard split uses two databases connected by a batch or streaming ETL job.
- TiDB runs both workloads on one cluster: TiKV for OLTP, TiFlash for OLAP.
- TiFlash replicates from TiKV continuously, not on a batch schedule.
- Analytical reads see a consistent, current snapshot instead of a stale copy.
Does HTAP eliminate the need for a separate data warehouse?
- For many workloads, yes: TiFlash serves the analytical queries a warehouse otherwise would.
- Large-scale historical analytics or heavy BI tooling may still call for a dedicated warehouse.
- TiDB integrates with Spark and Flink for workloads that need that extension.
- The core case, transactions plus real-time analytics, no longer requires one.
Is TiDB’s HTAP capability open source?
- Yes. TiDB, TiKV, and TiFlash are all open source under Apache 2.0.
- Self-managed deployment is free; TiDB Cloud adds a managed option.
- Raft-learner replication is part of the open-source core, not a paid feature.
- Source code and documentation are available at github.com/pingcap.