Agreed, it is somewhat confusing. This should help some - Read Committed (default isolation level of Sql Server) | Dirty Reads - Prevented | NonRepeatableReads - Possible | Phantom Rows - Possible | Readers block writers and writers block readers RCSI | Dirty Reads - Prevented | NonRepeateableReads - Possible | Phantom Rows - Possible | Readers do not block writers and writers do not block readers In ‘read committed’ isolation, your SQL statement views the most-recently committed data as of the moment each item is physically read. In other words, for read committed isolation, each row is locked briefly and physically read. RCSI improves on this by removing row locking part totally while reading of rows. It provides transaction with the point-in-time view of the committed data, where the point-in-time is the time when the transaction starts executing. When this isolation level is maintained, SQL server maintains row versioning and during read no shared locks are acquired physically because the entire transaction reads from the row version store rather than being accessed directly. MSDN says – “Transactions that modify data do not block transactions that read data, and transactions that read data do not block transactions that write data, as they normally would under the default READ COMMITTED isolation level in SQL Server” When RCSI is enabled, there are no shared locks. Any statement running with snapshot isolation cannot see any committed database modifications that occur after the statement starts executing. The longer the statement runs for, the more out-of-date its view of the database becomes, and the greater the scope for possibly-unintended consequences.