January 30, 2026
Consistency strikes back
Stonebraker on CAP theorem and Databases
Old post, new sparks: “Eventually” isn’t cutting it, say devs
TLDR: A revived 2010 post argues that “eventual consistency” doesn’t prevent real data loss and that strong consistency is often doable at scale. Commenters largely cheer, saying the last decade proved consistency wins—while others meme the missing date and shrug at small outages if data stays trustworthy.
A 2010 blog by database legend Mike Stonebraker just got dragged back into the spotlight, and the comments are on fire. Stonebraker’s take? The big, buzzy CAP theorem (the idea you can’t have perfect data, perfect uptime, and perfect network tolerance all at once) doesn’t excuse sloppy thinking. “Eventually consistent” — basically, “we’ll fix your data later” — won’t save you from bugs, fat‑finger deletes, or a full‑on cluster meltdown. He says many apps are simpler and safer with full consistency, and yes, it can scale. See CAP and the CACM context here.
Commenters sprinted into two camps. Team Consistency, led by nine_k, cheered that “eventual” isn’t enough for real‑world chaos, while redwood dropped a spicy line about winners choosing consistency over always‑on availability on the cloud — a.k.a., a little downtime is worth reliable data. sethev was impressed the post was from 2010, calling it a prediction that aged “like fine wine,” saying we’ve since learned that consistency can scale. Meanwhile, wippler and onethumb begged for a giant “(2010)” tag — prompting jokes that it “needs a label… eventually.”
Drama bonus round: the old debate over whether network meltdowns are “rare” got a side‑eye revival. But the mood is clear: don’t ditch strong consistency too soon — and please, timestamp your hot takes before the internet turns them into a meme.
Key Points
- •Stonebraker argues CAP is misapplied by NoSQL practitioners to justify eventual consistency.
- •Eventual consistency does not protect against application, administrative, or implementation errors that cause data loss.
- •Offline backups and techniques like deferred delete are needed to recover from non-CAP-related failures.
- •Network partitions are said to be relatively rare, though networking problems still occur and impact reliability.
- •Full (strong) consistency can be practical at scale; Amazon SimpleDB added support, giving developers choice.