People explain distributed database architecture at two levels. The first is the general one: replication, consensus, horizontal scale. The second is the level that decides whether a given system fits your workload, which is what its components actually are and what each one is responsible for. This page is about the second level for TiDB: the four components, how Raft keeps them consistent, and the one architectural choice that separates it from other distributed SQL databases.
What a Distributed Database Has to Solve
Every distributed database is answering the same three questions, and its architecture is the answer. How does data get spread across nodes without losing consistency? Why does the system keep serving when a node dies? How does it balance load as data grows unevenly?
The general trade-offs behind those questions, the benefits against a single node and the operational costs that come with distribution, are covered in our guide to distributed database use cases and in the piece on decentralized cloud computing. The rest of this page is specific: how TiDB answers all three.
TiDB’s Architecture: Components and Communication
TiDB separates compute from storage across four components, each of which scales independently.
| Component | Layer | What it does |
|---|---|---|
| TiDB server | Stateless SQL | Parses SQL, plans and optimizes queries, and coordinates reads and writes. Because it holds no data, instances can be added or removed without touching storage. |
| TiKV | Row storage | Stores data in ranges, each replicated across nodes as its own Raft group. Serves transactional reads and writes. |
| TiFlash | Columnar storage | Keeps a columnar replica of the same data as a Raft learner. Serves analytical queries. |
| PD (Placement Driver) | Cluster coordination | Tracks metadata and data distribution, schedules where replicas live, and transfers Raft leadership to balance load. It does not elect Raft leaders; each Raft group does that itself. |
That separation is what lets one cluster serve transactional and analytical workloads at once, which is the definition of a hybrid transactional/analytical processing (HTAP) database. It is worth naming what it rules out. Distributed SQL databases built for OLTP alone still need a second, separately maintained system for analytics. Cockroach Labs positions CockroachDB, the closest comparison on consensus design, for transactional workloads and expects analytics to land in a separate system through change data capture.TiKV and TiFlash stay in sync inside one cluster, so that second system, and the pipeline that feeds it, does not exist here.
Data Consistency and Fault Tolerance in TiDB
TiDB uses Raft consensus for replication and two-phase commit for transactions, and the distinction matters. TiKV replicates each range of data across nodes as a Raft group, and a write to that range becomes durable once a majority of its replicas acknowledge it.. A transaction that touches multiple ranges commits through two-phase commit across those groups, so it is atomic even though no single node holds all of it.
Fault tolerance falls out of the same design. Every range has multiple replicas, so when a node fails, only the Raft groups it belonged to elect new leaders, and every other range keeps serving uninterrupted. There is no cluster-wide failover event and no single primary to promote.
Scalability and Load Balancing in TiDB
TiDB scales out by adding nodes, and the compute-storage separation is what makes that transparent to applications. Add TiDB servers for query capacity, add TiKV nodes for storage and write throughput, and add TiFlash nodes for analytical capacity. No resharding, and no application changes.
Load balancing is PD’s job. PD watches where data and traffic land across the cluster and moves replicas and Raft leadership as workloads shift, so a range that suddenly gets hot doesn’t pin one node while others sit idle.
TiDB in Production: MNC Bank, Flipkart, and Trip.com
Three deployments show what the architecture buys across different pressures.
- MNC Bank runs critical finance operations with strict consistency requirements, and reported 10x higher throughput, 50% lower latency, and 85% faster backups after adopting TiDB.
- Flipkart relies on horizontal scaling and replica availability to hold up through e-commerce peak load without manual resharding.
- Trip.com uses TiDB for real-time data processing and financial settlement, where booking and payment records have to stay consistent across regions rather than get reconciled afterward.
The common thread is workloads that need transactional correctness and current analytics on the same data. This is the case the two-engine design is built for.
TiDB in Cloud-Native Environments
TiDB runs on Kubernetes through TiDB Operator, which handles deployment, scaling, upgrades, and failover as cluster operations rather than manual runbooks. Because each component scales independently, capacity changes are a matter of changing a replica count.
The same properties support multi-region disaster recovery: replicas distribute across geographic regions or cloud availability zones, so losing a zone costs capacity rather than availability. TiDB Cloud offers the same architecture as a managed service for teams that would rather not operate it themselves.
The Takeaway
TiDB’s architecture comes down to four components and one choice: separate compute from storage, replicate per range with Raft, let PD balance the result, and keep a columnar replica in the same cluster so analytics never needs a second system. That last part is what distinguishes it from distributed SQL databases built for OLTP alone.
If you want implementation-level detail on how the components fit together, the TiDB architecture documentation covers each one in depth.
FAQs
What makes TiDB’s architecture different from other distributed SQL databases?
The columnar engine. Most distributed SQL databases, CockroachDB among them, are built for transactional workloads only. This means analytics needs a separate warehouse and a pipeline to feed it. TiDB pairs the TiKV row store with the TiFlash columnar store inside the same cluster, so both workload types read the same data without a second system to maintain.
How does TiDB achieve both strong consistency and high availability?
Through Raft. A write commits once a majority of its range’s replicas acknowledge it, which guarantees consistency, and if a node fails the remaining replicas of each affected range elect a new leader and keep serving, which preserves availability. Because replication happens per range rather than per cluster, a node failure degrades capacity instead of interrupting service.
Can TiDB run analytical queries without a separate data warehouse?
Yes. TiFlash maintains a columnar replica of the data as a Raft learner, and validates its log index against TiKV before serving a query, so analytical queries read data consistent with committed transactions. There is no export job and no second database to operate.