One machine ran out of room. Now it's copied, split, and scattered across a dozen more - and every clue on this board is about keeping the story straight once it is.
A single database on a single machine has the same ceiling as any single machine - finite CPU, RAM, disk. Past that ceiling you split the data: copy it (replication) and/or divide it (sharding). The moment data lives on more than one machine talking over a network, you inherit a fact you can't engineer away: networks partition. Every other topic on this board - CAP, quorums, consistent hashing - is an answer to the same question forced by that one fact:
SQL vs. NoSQL is a downstream decision, not a first principle - it's about which guarantees you need enough to justify a rigid schema, versus which flexibility you need enough to give some of those guarantees up.
A single DB writes to a log before applying anything (durability) and reads through an index (a B-tree or LSM-tree) instead of scanning everything. Everything below is what happens once one machine isn't enough.
Tap any card to open the evidence.
Single-leader relational, strong ACID guarantees, read replicas for read scaling. Sharding is a manual/add-on concern (e.g. Citus for Postgres), not built in.
Document model, flexible schema. Multi-document transaction guarantees have strengthened over the years.current specifics unverified
Wide-column, leaderless replication, tunable N/W/R quorum, consistent hashing for partitioning - direct descendant of Amazon's Dynamo paper. AP-leaning by default.
Also Dynamo-lineage: consistent hashing, quorum reads/writes, eventual by default with a strongly-consistent read option.current defaults unverified
Strong consistency across a globally distributed DB using tightly synchronized clocks (TrueTime). Still bound by CAP during an actual partition.
Key-value, typically single-leader with async replicas - simpler replication model than the quorum-based systems above. (Full profile: Caching case file.)
Write, then immediately read a replica that hasn't caught up - the read-your-own-writes problem. Fix: route a user's own reads to the leader right after they write.
A partition makes replicas think the leader is dead when it isn't - two nodes both accept writes as "the leader." Both sets need reconciling once it heals.
One key gets disproportionate traffic, overwhelming its shard even though sharding is working exactly as designed. Same fix as a hot key on a hash ring: split it or replicate it specifically.
Moving data while staying online usually needs a dual-write window. A bug there can silently drop or duplicate writes.
Breaks naive last-write-wins conflict resolution, and is the exact uncertainty Spanner's TrueTime is built to bound.
Needs distributed coordination (two-phase commit or a saga) - both add latency and new failure modes a single shard never had.
Duplicated data for read speed means every write must update every copy. Miss one and it's a silent correctness bug.
A single-leader database handles roughly 5,000 writes/second comfortably.
The decision this forces: past a certain write volume, replication doesn't help the bottleneck at all - only sharding does, because replicas copy data, they don't divide the write load.
| Decision | Options | Pick based on |
|---|---|---|
| SQL vs NoSQL | Relational / document / key-value / wide-column / graph | Multi-row transactions, known schema → SQL. Flexible schema → document. Fast key lookup → key-value. Huge write volume → wide-column. Connected data → graph |
| ACID vs BASE | Strict transactions / eventual consistency | Correctness-critical → ACID. Must stay available through partitions → BASE |
| Isolation level | Read uncommitted → serializable | Default read committed; go stricter only for a specific anomaly you must prevent |
| Replication | Single-leader / multi-leader / leaderless | Simplicity → single-leader. Multi-region writes → multi-leader. No write SPOF → leaderless + quorum |
| Quorum (N,W,R) | Tune W+R vs N | Guaranteed-fresh reads → W+R > N. Speed/availability over freshness → W+R ≤ N |
| Sharding | Range / hash / directory / consistent hashing | Range queries → range. Even load → hash. Max flexibility → directory. Frequent resharding → consistent hashing |
| CAP choice | CP / AP | Can't tolerate stale data → CP. Must stay available through partitions → AP |
| Normalization | Normalized / denormalized | Write correctness → normalize. Read speed at scale → denormalize (update every copy) |