3 ms·

So immutable records only makes business sense in databases too small to benefit from immutable records (where you can just version the entire database, for a "

So immutable records only makes business sense in databases too small to benefit from immutable records (where you can just version the entire database, for a "few hundred megs")? I don't understand what FAANG has to do with this. Medium or large non-tech companies commonly have business critical databases in the hundreds of gig range. Acting like medium to large databases aren't common in business is just outright odd. The argument also doesn't address what I asked (business case for this vis-a-vis cost).

josephg 6y ago
> So immutable records only makes business sense in databases too small to benefit from immutable records My claim is that discarding historical data is an optimization. Its an optimization that should be off by default and turned on when needed. Archiving and compacting history should be something you do only need to do when your database size gets out of control. For small databases there's no reason to throw away historical records at all - and having an immutable log of records and updates should be the default.