“The term “snapshot” reflects the fact that all queries in the transaction see the same version, or snapshot, of the database, based on the state of the database at the moment in time when the transaction begins. No locks are acquired on the underlying data rows or data pages in a snapshot transaction, which permits other transactions to execute without being blocked by a prior uncompleted transaction. 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. This non-blocking behavior also significantly reduces the likelihood of deadlocks for complex transactions.”
Enabling this feature does carry risks. Concurrency control implementation and temp table size have to be considered. Given we had years of development spent on the system project management explored other options. Considerable time was invested in alternative solutions. To make things more difficult we were not able to reproduce the scenarios causing deadlocks in a test or development environment. Multiple releases of new versions failed to reduce the errors in production.
Finally we convinced management that the risk was manageable and turned on Snapshot Isolation. It solved the issue immediately and no side effects ever arose.
After this experience I made it a rule to enable Snapshot Isolation on SQL Server from the beginning on any new project. Why this isn’t turned on by default is a mystery… If you develop on a different RDBMS check your option (most systems have a similar setting). While you develop you will continuously test against Snapshot Isolation level. If you have to enable it late in a project make sure you run regression tests.