핵심 요약
- TiDB differs from a traditional database in three ways: it scales out instead of up, separates storage from compute, and recovers from failures through Raft rather than manual failover.
- Raft commits a write only after a majority of replicas confirm it, so a node loss or network partition costs no committed data.
- Surviving replicas elect a new leader within seconds, with no operator in the loop.
- Tuya measured 150 μs P99 query latency and 75% lower hardware cost on this architecture.
A node failure in a traditional database usually means manual failover: paging someone, promoting a replica, and hoping the recovery finishes before the outage costs more than the engineering time it took to fix. 티DB differs from traditional databases in three concrete ways. It scales horizontally instead of vertically, it separates storage from compute, and it recovers from node or network failures automatically through Raft consensus, without a human in the loop.
Fault Tolerance: Raft Consensus vs Manual Failover
Traditional databases typically rely on a primary/replica setup. If the primary fails, a human, or a fragile automated script, has to detect the failure and promote a replica, and the cluster can lose data written just before the failure in the process.
TiDB replicates data across nodes using the Raft consensus algorithm, deployed across multiple zones and regions. The cluster acknowledges a write only once a majority of replicas confirm it, so a single node failure, or even a network partition, neither takes the cluster down nor loses committed data. When a node fails, the surviving replicas elect a new Raft leader among themselves within seconds, and the application keeps writing without operator intervention.
What Actually Happens During a Node Failure
The phrase “automatic failover” hides the part that matters. Walk both systems through the same failure, moment by moment, and the difference stops being a marketing claim.
The Raft Sequence in TiDB
A TiKV node holding the leader replica for several Regions loses power. Writes to those Regions stop returning immediately. Their followers stop receiving heartbeats and each waits out a randomized election timeout, which keeps them from all campaigning at once.
The first follower to time out becomes a candidate and requests votes from the others. Raft grants a vote only to a candidate whose log is at least as current as the voter’s own, so a replica that had fallen behind cannot win. Once a majority votes, that replica becomes leader for those Regions and starts accepting writes again.
No committed write disappears in that handoff, and the reason is structural rather than lucky. A write committed only after a majority of replicas persisted it. Any majority that can elect a leader therefore overlaps, by at least one node, with the majority that accepted every committed write. The winning candidate holds those entries by definition.
Meanwhile PD notices the store has stopped reporting, marks it down, and schedules replacements for the Regions now running below their replica count. The cluster returns to full redundancy without anyone filing a ticket.
The Primary/Replica Sequence
The same failure on a traditional primary/replica setup starts identically: the primary dies and writes stop returning. From there the paths diverge, because detection and promotion are separate systems from replication rather than the same one.
Something has to notice. That something is monitoring, a proxy health check, or a person reading an alert, and each has its own interval and its own false-positive rate. Then something has to decide, because promoting during a brief network partition risks two primaries accepting writes. Then something has to promote, repoint the surviving replicas, and move application traffic to the new address.
Configuration settles the data question long before any of that, at build time rather than during the outage. Under asynchronous replication, a transaction the primary already acknowledged to the client may never have reached a replica, and it is gone. Under synchronous replication the loss window closes, but every write pays the replica round trip. That tradeoff is exactly the one a Raft majority sidesteps: it waits for most replicas, not all of them and not none.
The Same Failure, Side by Side
| Moment | TiDB (Raft) | Traditional Primary/Replica |
|---|---|---|
| Node fails | Writes to Regions led by that node stop returning | Writes to the primary stop returning |
| Detection | Followers see missing heartbeats; a randomized election timeout elapses | Monitoring, a proxy health check, or a person notices |
| Decision | None required. Raft’s voting rules decide who is eligible | Someone judges whether this is a real failure or a network blip |
| Promotion | Surviving replicas elect a new leader among themselves | An operator or failover script promotes a chosen replica |
| Committed data at risk | None. The electing majority overlaps the majority that accepted every commit | Under async replication, any transaction acknowledged but not yet shipped |
| Application impact | Retries succeed once a new leader is up; the connection string never changes | Depends on whether a proxy, VIP, or config change moves traffic |
| Back to full redundancy | PD re-replicates the under-replicated Regions onto healthy stores | Rebuild a replica by hand and repoint the survivors at the new primary |
The asymmetry worth taking away is not that one recovers faster. It is that TiDB uses one mechanism where a traditional setup uses three. The majority that makes a write durable is the same majority that elects a leader, so the durability guarantee and the failover guarantee cannot drift apart. In a primary/replica system, you configure replication, health detection, and promotion separately, which means the recovery behavior is only as good as the weakest of the three, and you find out which one that is during the outage.
Verified Result: Tuya’s Latency and Cost Benchmark
Tuya, an IoT platform serving more than 384,000 developers, needed average query latency under 10 ms. In its own evaluation, Tuya tested AWS Aurora and Apache Ignite and found that neither met that bar for its workload. On TiKV, Tuya measured P99 query latency of 150 μs and write latency of 360 μs, both well under a millisecond, while cutting hardware cost by 75%. That result comes from the same Raft-based architecture described above: replicating only what consistency requires, rather than keeping a full copy on every node.
Scaling and MySQL Compatibility, in Brief
TiDB also scales horizontally by separating the TiDB SQL layer from TiKV (row storage) and TiFlash (columnar storage), so capacity grows by adding nodes rather than upgrading one machine. It stays compatible with the MySQL protocol, which keeps migration effort low. Two sibling articles cover this ground in full: Advantages of TiDB Over Traditional Relational Databases 그리고 TiDB vs Traditional SQL.
The Difference Is Architectural, Not Incremental
The gap between TiDB and a traditional database is not a matter of degree. Automatic Raft-based recovery replaces manual failover entirely, and a benchmark like Tuya’s shows what that looks like once production load is on it.
Start with a free TiDB Cloud Starter cluster and kill a node to watch the failover behavior against your own workload.
TiDB vs Traditional Database FAQs
What Is the Key Architectural Difference Between TiDB and a Traditional Database?
TiDB separates storage from compute, while a traditional database runs both on one machine. TiDB also replicates and recovers through Raft consensus automatically, where traditional databases typically depend on manual or semi-automated failover. Those two differences drive most of the others.
How Does TiDB Handle Node or Network Failures Differently Than a Traditional Database?
Raft consensus requires a majority of replicas to confirm a write before it commits, so a committed write already exists on multiple nodes when a failure hits. A failed node triggers an automatic leader election among the surviving replicas. Nobody promotes a replica by hand, and the cluster loses no committed data.
Does TiDB Require Manual Intervention to Recover From a Network Partition?
No. Raft-based recovery happens automatically, usually within seconds, and multi-zone and multi-region deployment options add further resilience. Tuya’s benchmark shows this holding at production scale, with P99 query latency at 150 μs.