Which row-versioning transaction isolation level do you use?

We're using READ COMMITTED SNAPSHOT because it provides just about everything we want without requiring our developers to make a single bit of change to their code. That's a pretty major win for us. Also, because it's a database setting as opposed to a connection setting we don't have to sweat the loss of remote transactions.

We used read committed isolation for 2 reasons:

1. We didn't have to change existing queries that already used read committed isolation.
2. It is recommended by Microsoft for most situations.

Once we switched this option on, we saw a dramatic reduction in ASP.NET page timeouts that had been occurring due to blocking.

In my last job we used SNAPSHOT, purely for the transactional consistency. We also saw a massive reduction in locks when moving from READ COMMITTED (without row versioning) to SNAPSHOT.

tempdb usage and bandwidth was not an issue for us, however, if it was, we would have considered READ COMMITTED with row versioning in order to reduce that load slightly.

We used READ COMMITTED with row versioning enabled in our large billing system (with a couple of hundreds of millions of records) and successfully reduced the locks and increased the concurrency. It was a quick and easy way of solving the issues, without any code changes.

Yep, read committed with row-level versioning. No application changes necessary and it works like a charm. I was concerned about the impact on tempdb but it hasn't got that big and doesn't seem to be under stress. (And that's on virtualised RAID 5 on a virtual machine - damn, I'm looking forward to our new hardware!)