Database updates were creating huge performance problems for Facebook in their early years as they scaled up.
Some MySQL engines would lock the entire table for every UPDATE query. No one else can update their profile and no one can view any one else’s profile until that save was complete. Every time someone hits save, all of Facebook gets locked out.
The engineers solved that problem by trading disk space for response time. No more UPDATE or DELETE queries, you can only INSERT new records. They made their database immutable. Storage is now absurdly cheap and rapidly approaching free—it makes sense to make the database bigger in order to make the site faster.
There were no more blocked reads, or writes. Updates finish faster. Reads were insignificantly longer to sort the versions and select the most recent.
It created built-in backwards compatibility. The previous version of that record was always available, which made it possible to link GUIDs to specific versions, rather than having a related record just update itself out from under you.
You get a modification history for no additional cost, which can be very useful for moderation, analytics, or even advanced editing features like revert changes.
It also made scaling reads easier. One version of the MySQL architecture called for a small number of heavy-lifting master databases, which processed writes. Those writes would then be propagated to as many read-only slave databases as was necessary for current traffic levels.
In an UPDATE approach, propagating updates requires either that we lock resources in every database synchronously, or that we allow records to go out of sync—two bad answers. With the INSERT approach, the newest version of a record can propagate out to read slaves asynchronously. The worst thing that can happen is a brief delay in before updates go live.
Immutability was originally a feature of pure functional programming languages that has such great benefits that we’re starting to experiment with using it in other ways when designing software. Immutable databases is just one. One of the applications I find most promising is the idea of immutable architecture—I never change code, I can only replace code.