Isolation refers to the visibility of transaction operations to other operations happening in parallel.

An example of why isolation levels are essential is described in the following scenario:

• Transaction A updates user 1's account balance from 50 to 100, but does not commit the transaction.
• Transaction B reads user 1's account balance as 100.
• Transaction A is rolled back, reverting user 1's account balance to 50.
• Transaction B thinks that user 1 has 100 pounds, whereas they only have 50.
• Transaction B updates user 2's value, by adding 100 pounds. User 2 receives 100 pounds out of thin air from user 1, since user 1 only has 50 pounds in their account. Our imaginary bank is in trouble.

Isolation typically has four levels, with the most to the least strict, as follows:

• Serializable
• Repeatable read
• Read committed
• Read uncommitted

The problems we can run into from the least to the most serious, and depending on the isolation level, are as follows:

• Phantom reads
• Non-repeatable reads
• Dirty reads
• Lost updates

Losing data about an operational update is the worst thing that can happen in any database, because this would render our database unusable and make it a store of data that cannot be trusted. That's why, in every isolation level, even read uncommitted isolation will not lose data.

However, the other three issues may also arise. We will briefly explain what these are in the following sections.