We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
This idea carries a full system design question on its own. Each walks through the full answer.
System Design Masterclass · Database Types Storage
Free preview: the first 2 parts of this 8-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Database Types Storage
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
For over a decade, the database world presented a false dilemma:
Option A: Traditional (PostgreSQL, MySQL). transactions, rich queries, mature tooling. But scaling beyond a single node is painful, manual sharding, cross-shard transactions, application-level routing.
Option B: (Cassandra, MongoDB, DynamoDB). Horizontal scalability, automatic , high availability. But you give up ACID transactions, JOINs, and the SQL query language. Your application code gets more complex to compensate.
For years, engineers accepted this trade-off. Need scale? Give up SQL. Need SQL? Stay on one node and pray it's big enough.
Then Google published the Spanner paper in 2012. They built a globally distributed SQL database with ACID transactions that spans data centers across continents. It uses synchronized atomic clocks (TrueTime) to order transactions across the planet.
Google proved the trade-off was false. You could have both SQL and horizontal scale. The NewSQL movement was born.
CockroachDB (inspired by Spanner), TiDB, YugabyteDB, and PlanetScale (Vitess-based) all tackle this same problem, distributed SQL databases that scale horizontally without sacrificing the SQL interface or ACID guarantees.
NewSQL databases combine three things that were previously considered mutually exclusive:
1. Full interface. Standard SQL with JOINs, transactions, indexes, foreign keys. Your existing PostgreSQL or MySQL application can migrate with minimal changes. CockroachDB implements the PostgreSQL wire protocol. TiDB implements the MySQL wire protocol.
2. transactions across distributed nodes. A transaction that touches data on nodes in New York and London either commits everywhere or rolls back everywhere. This is the hard part, and what separates NewSQL from "sharded MySQL with application-level coordination."
3. Horizontal scalability. Add nodes to add capacity. Data is automatically sharded and rebalanced across nodes. No manual partition keys, no application-level routing.
How they achieve distributed ACID:
The key innovation is distributed . CockroachDB uses the Raft consensus protocol. Spanner uses Paxos. Each piece of data has multiple replicas across nodes, and writes must be acknowledged by a majority () before committing.
Transaction: UPDATE accounts SET balance = balance - 100 WHERE id = 'alice';
UPDATE accounts SET balance = balance + 100 WHERE id = 'bob';
1. Alice's data lives on Node A (replicated to B and C)
2. Bob's data lives on Node D (replicated to E and F)
3. Both updates are proposed to their respective Raft groups
4. Quorum (2/3) acknowledges each update
5. A transaction coordinator ensures both commit or both roll back
This is dramatically more complex than a single-node PostgreSQL commit. The is higher, cross-node consensus adds milliseconds to each transaction. But the system scales horizontally and survives node failures without data loss.