[havkom]

In many real world applications using common databases you do not always need “transaction safety”, in particular when reading data for statistical purposes.

Performance gains and not blocking the database for many other readers and writers will in many scenarios outweigh the possibly of reading uncommitted/dirty data.

Use:

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

(whether you are are querying from within a transaction or not)

and you may be surprised how this may solve many of your performance problems in your application/service.

[freels]

This advice is highly implementation specific and unnecessarily dangerous. For read only transactions, a well designed system will be able to provide SNAPSHOT isolation with little negligible perf impact compared to READ UNCOMMITTED. When combined with SERIALIZABLE write transactions, reads at SNAPSHOT are equivalent to SERIALIZABLE.

For transactions which must write, the entire point of this article is that anything less than SERIALIZABLE leaves you subject to anomalies whose affects on your data can be very difficult to predict beyond trivial scenarios.

If you must lower consistency for performance's sake, then so be it, but I would strongly argue that should be the exception, not the rule, and not be a decision made lightly.

[stubish]

It can certainly solve performance problems, in much the same way as turning of fsync. Even a contractor contracted specifically to fix a performance problem shouldn't do this without understanding how this will affect the particular application, or they open themselves to professional malfeasance (if noticed; otherwise they will likely get the contract to fix the data corruption problem since they did such a good job last time...)