Demystifying Database Systems: An Introduction to Transaction Isolation Levels

Glad to see to see this post on HN. I'm the author and happy to respond to questions in this thread.

&gt; If any of my readers are aware of any real lawsuits that came from application developers who believed they were getting a SERIALIZABLE isolation level, but experienced write skew anomalies in practice<p>Doubt this ever really happened. Can hardly imagine debating serializability in a court of law Oracle v. Google was bad enough.

It seems grossly irresponsible to encourage the use of serializable without even mentioning deadlocks. I guess you won&#x27;t have deadlocks if your db interprets as serializable as &quot;lock the whole database on transaction start&quot;, but that means literally no concurrency whatsoever, which also seems like a grossly irresponsible recommendation.<p>I dunno, maybe I didn&#x27;t get the memo that the database of the future will be single-threaded.

In many real world applications using common databases you do not always need “transaction safety”, in particular when reading data for statistical purposes.<p>Performance gains and not blocking the database for many other readers and writers will in many scenarios outweigh the possibly of reading uncommitted&#x2F;dirty data.<p>Use:<p>SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED<p>(whether you are are querying from within a transaction or not)<p>and you may be surprised how this may solve many of your performance problems in your application&#x2F;service.