When a funds transfer debits one node but the matching credit never lands on another, you are looking at the exact failure that data consistency in distributed systems with 티DB is built to prevent. Spread a transaction across machines and you inherit new ways for it to half-complete. A node dies mid-write, a network partition splits the cluster, or two writes race for the same row. For a payments ledger, a partial commit is not a slow query. It is wrong data. TiDB closes that gap with a Percolator-style two-phase commit layered over multi-version concurrency control (MVCC), and it does so by default. This article explains how that protocol keeps distributed transactions ACID-compliant, and how the TPC-C benchmark verifies it under load.
How Does TiDB Guarantee ACID Transactions in a Distributed Database?
TiDB guarantees ACID transactions across a cluster using a Percolator-style two-phase commit running over MVCC. A transaction that writes rows on separate nodes commits as one unit or not at all, and concurrent readers see a stable snapshot instead of partial results. This is the default and only transaction path in TiDB. It is not a mode you configure, and there is no setting that trades isolation away for throughput.
Consistency here is a property of the cluster, not of any single node. The CAP theorem states the constraint plainly: under a network partition, a system chooses between consistency and availability. TiDB chooses strong consistency, so a read reflects the most recent committed write rather than converging toward it later as an eventually consistent store would. For the wider treatment of consistency models, see data consistency in distributed systems.
Percolator and MVCC: How the Commit Protocol Works
TiDB implements transactions with the Percolator model, an implementation of two-phase commit, running over MVCC. One key in the transaction becomes the primary key and the rest are secondary keys.
The two phases are prewrite and commit. During prewrite, TiDB locks every key it will change and stages the new values, marking the primary key as the lock the others point to. During commit, TiDB commits the primary key first. That single write is the atomic decision point. Once the primary key commits, the transaction is durable, and the secondary keys resolve to the same outcome even if a node restarts mid-commit. TiDB then cleans up the remaining locks asynchronously. This is what delivers Atomicity across nodes.
MVCC delivers Isolation without blocking. Every write creates a new version stamped with a commit timestamp instead of overwriting the row in place. A read requests the version as of its own start timestamp, so it sees a stable snapshot and never waits on an in-flight write. Readers do not block writers, and writers do not block readers. The isolation level is Snapshot Isolation, exposed as REPEATABLE-READ for MySQL compatibility.
The other two properties come from the layers on either side. The SQL layer enforces Consistency, rejecting any commit that would violate a schema definition, primary key, unique index, or other constraint. Durability comes from Raft. TiDB replicates every committed write across TiKV nodes and acknowledges only after a majority has persisted it, which is what makes the same guarantees hold in geo-distributed deployments. The Multi-Raft layer providing this is covered on the sibling consistency page.
Verified at Scale: The TPC-C Benchmark Result
The question every evaluator asks is what these guarantees cost under load. TPC-C is the standard benchmark for online transaction processing. It models a wholesale supplier and measures how many NewOrder transactions a system commits per minute (tpmC) under a concurrent mix of order-entry, payment, and delivery transactions against the same rows.
On a TiDB Cloud Dedicated cluster running v8.5.0, two TiDB nodes at 16 vCPU and 32 GiB each plus three TiKV nodes at 16 vCPU and 64 GiB each on AWS, TiDB sustained 103,395 tpmC at 200 threads against a 1,000-warehouse dataset, and 73,875 tpmC at 100 threads. Each concurrency level ran for two hours. That workload exercises the exact conditions the commit protocol exists for, with many clients writing shared rows at once and every transaction expected to be atomic and isolated. A tpmC figure measures ACID transactions holding at throughput, not raw speed.
ACID Transactions in Production: MNC Bank
A funds transfer is the textbook case for why atomicity is not negotiable. Two writes, a debit and a credit, must both land or neither can. A partial commit does not degrade the user experience. It creates money that does not exist.
MNC Bank, an Indonesian private bank operating since 1989, runs its Motion Apps mobile platform on TiDB, handling fund transfers and real-time notifications. The bank’s legacy database hit bottlenecks at month-end and payout days, where workloads rose tenfold. Peak load is when transaction correctness is most at risk, because contention on shared rows is highest.
Before cutover the team ran load tests and failover simulations, and used TiCDC to mirror changes back to the legacy database so both systems stayed consistent through the transition. Migration took two weeks, with a three-hour cutover window.
The bank now handles a tenfold throughput increase at peak and cut application latency by 50%, with TiCDC replicating to a secondary cluster at the disaster recovery site. The throughput gain required no relaxation of transaction guarantees, because the commit path described above is the only path TiDB offers. Read the full MNC Bank case study.
Correctness under concurrency is not a feature you enable in TiDB. It is the commit protocol, and the benchmark numbers are what it costs.
Try it on your own workload. Start with TiDB Cloud Starter, free, or work through the transaction guide for developers 그리고 TiDB Labs.
자주 묻는 질문
How does TiDB implement ACID transactions across multiple nodes?
TiDB implements transactions using the Percolator transaction model, which is an implementation of two-phase commit, combined with multi-version concurrency control (MVCC). The transaction designates one key as the primary key and treats the rest as secondary keys, then commits in two phases: prewrite, which locks and stages every change, and commit, which writes the primary key as a single atomic decision point. Raft replicates each committed write across TiKV nodes before acknowledging it. A transaction spanning many nodes commits everywhere or nowhere.
Does TiDB guarantee ACID compliance by default, or is it an optional setting?
ACID compliance is the default behavior, not a mode you enable. Every transaction runs the same two-phase commit and MVCC path, with Raft underpinning durability on every write. TiDB offers both optimistic and pessimistic transaction modes, and clusters created from v3.0.8 onward use pessimistic mode by default. Both are ACID; the modes differ in when lock conflicts are detected. The isolation level is Snapshot Isolation, exposed as REPEATABLE-READ for MySQL compatibility. SERIALIZABLE and READ-UNCOMMITTED are not supported.
What is the TPC-C benchmark and why does it matter for transactional databases?
TPC-C is the industry-standard benchmark for online transaction processing. It models a warehouse-and-order system and measures how many NewOrder transactions a database commits per minute (tpmC) under a concurrent mix of reads and writes against shared data. It matters because it tests where correctness and concurrency meet, with the same rows updated by many transactions at once. A tpmC result reported alongside its cluster configuration shows the system holds its ACID guarantees at real transactional load.