**Summary**

1. If you have locking problems then you have a problem with your code: it isn't the database engine
2. It isn't a magic bullet
3. You may add more problems

**Load**

It will also increase load on your tempdb and [CPU][2]. Also see: 

- ["Performance Impact: The Potential Cost of Read_Committed_Snapshot"][3] (Linchi Shea)

**Safety**

Most important, snapshot isolations *are not safe* in many cases *by default*. Read ["Snapshot isolation" (Wikipedia)][4] for more on write-skew anomalies. The next section is "Making Snapshot Isolation Serializable" to get around this.

> In general, therefore, snapshot isolation puts some of the problem of maintaining non-trivial constraints onto the user, who may not appreciate either the potential pitfalls or the possible solutions. The upside to this transfer is better performance.

Also see:

- ["The Potential Dangers of the Read Committed Snapshot Isolation Level"][5] (JimMcLeod, disputed in comments by Alex Kuznetsov)
- http://coderjournal.com/2008/08/deadlocked-read-committed-snapshot-explained/
- [Serializable vs. Snapshot Isolation Level, the Marble problem][6] (Craig Freedman)
- http://sqlblog.com/blogs/alexander_kuznetsov/archive/2011/08/02/reads-involving-udfs-under-read-committed-snapshot-may-seem-inconsistent.aspx (Alex Kuznetsov)

  [1]: http://en.wikipedia.org/wiki/Multiversion_concurrency_control
  [2]: http://sqlblog.com/blogs/alexander_kuznetsov/archive/2008/07/12/cpu-overhead-for-higher-isolation-levels.aspx
  [3]: http://sqlblog.com/blogs/linchi_shea/archive/2007/10/05/performance-impact-the-potential-cost-of-read-committed-snapshot.aspx
  [4]: http://en.wikipedia.org/wiki/Snapshot_isolation#Definition
  [5]: http://www.jimmcleod.net/blog/index.php/2009/08/27/the-potential-dangers-of-the-read-committed-snapshot-isolation-level
  [6]: http://blogs.msdn.com/b/craigfr/archive/2007/05/16/serializable-vs-snapshot-isolation-level.aspx