Isolation is the third characteristic of the ACID property. With this property, our goal is to make all transactions completely separate from each other (serializable). However, some applications do not require complete isolation. Therefore, we define some isolation levels that are less strict than full isolation. Generally, there are five isolation levels defined.   Read Uncommitted: There are no locks at all. Concurrent transactions can read or write uncommitted data from other transactions. In database languages, the DBMS is said to allow dirty reads.   Read Committed: In this DBMS does not allow dirty reads at this level. At this level, each transaction holds a read/write lock on the current row and releases it only when it commits changes. This isolation level still allows non-repeatable reads. In other words, if a transaction reads the same row, the transaction will return different values. See the following image for more clarity. Obviously, dirty reads are not allowed, but there are still non-repeatable reads.  Repeatable Read: As explained earlier, the problem with read committed isolation level was non-repeatable reads. To avoid non-repeatable reads, each transaction should hold read locks on the rows it reads and write locks on the rows it writes (insert, update, delete, etc.) until it commits the changes. This isolation level is a repeatable read. However, this isolation level has one more scenario that makes the database inconsistent. Inserting or deleting new rows into a table and then running a range query gives inconsistent results. See the example below. The same query in Transaction 1 returns two different results. This scenario is called Phantom Reading. Serializable: Serializable level is the highest isolation level. As we saw in Repeatable Reads, phantom reads can occur. To prevent phantom reads, locks should be held on the entire table, not on the row. The following diagram shows an overview of all previous isolation levels.   Snapshot: This level of isolation is different from the other isolation levels discussed so far. Others were based on locks and blocks. It does not use locks. With this isolation level, when a transaction modifies a row (that is, inserts, updates, and deletes), the committed version of the modified row is copied to the temporary database (tempdb) and versioned. This is also known as row versioning. Then, when another session tries to read the modified object, tempdb returns the committed version of the object to that operation.   If talking about snapshot isolation sounds fundamentally different than other isolation levels, then it is. Snapshot isolation is based on an optimistic model, while other isolation levels are based on a pessimistic concurrency control model. The optimistic model assumes conflicts are rare, chooses not to prevent conflicts, and deals with conflicts when they do occur.   A must-know for anyone heading into the technical round, this is a frequently asked Database interview question.