The default transaction isolation level for every major database is not ACID. Enabling the required serializability tends to make performance terrible, and so most don't.
is trivial, no?
> ...tends to make performance terrible
I've heard this a lot but never seen any figures - anyone have any numbers/experience?
(edit: and most apps I've worked with didn't need serialisability, either because they were working with a snapshot of data or absolutely precise answers weren't needed)
(On your edit: The problem is not knowing when you're being hit by it. Even just maintaining a limit on total size of uploaded files or such, for example, is nontrivial under default isolation levels.)
And, BTW, deadlocks can most definitely happen using the default Read Committed isolation level.
Per your 2nd para, I simply don't understand, can you clarify?
For the last, I was pointing out that people don't necessarily know when they hit race conditions or other transaction isolation faults; they're one of the hardest things to debug or notice. It would be easy to believe that a transaction that confirms a file update would not take a user over their quota and then updates the file would, per ACID, actually ensure the user doesn't exceed their quota. But the default transaction isolation levels don't provide that.
Nonetheless if you're going to base your company's product around a database or anything else for that matter, you really had better get yourself sorted out WRT your tools, or it can become horribly expensive to fix or even fatal to your company.