The Database Google Gave Away, and Then Took Back

Bigtable, Dynamo and Spanner, and the long argument about what to sacrifice when scale, speed and correctness collide

Complexity doesn’t disappear when you change technology. It moves to another place.

The Checkout Button

A user taps “Pay.” The screen shows a spinner, then a green check mark. Behind that check mark, five things have to be true:

1. The order exists.
2. The account was charged.
3. The inventory was decremented.
4. The payment record was written.
5. The merchant was notified.

Those five facts may live in different tables, different services, and sometimes different data centers.

Now break it. The charge succeeds, but the inventory decrement fails. The charge succeeds but the order service times out before it hears back. Two data centers each accept a different edit to the same order while the link between them is down. Which copy do you believe?

This is not an ordinary bug. It is the central problem a database exists to solve. A database doesn’t just store data. It defines how data relates to other data and constrains how that data may change. It also decides what “correct” means when operations overlap, machines die, and networks split.