I believe it still has to be chosen, and the MS term is 'Read Committed Snapshot'. Everything is a tradeoff, read committed snapshot makes your tempdb busier (s

I believe it still has to be chosen, and the MS term is 'Read Committed Snapshot'. Everything is a tradeoff, read committed snapshot makes your tempdb busier (since it is involved in versioning), and balloons up the default size of a row in a table. With RCS you end up adding 14 bytes of overhead to each row, and which otherwise wouldn't be there. So imagine a table with a single integer column and 1 billion rows. Instead of the 9 byte per row overhead (7 bytes for row metadata and 2 bytes for the page offset), you instead have 23 bytes, plus the 4 bytes to hold the int32. Without RCS on, that row would only have a 9 byte overhead and the rowsize would be 13 bytes. so 1billion * 27bytes = 25.14 GB 1billion * 13bytes = 12.11 GB There are some other performance tradeoffs (walking row version values, pagesplits when updating records without rowversions after converting the database, et cetera). Ultimately, MVCC is great for contention, but it stinks if you're trying to efficiently pack in data. For an alternative perspective, I sometimes bemoan the size of tables in postgres because of the mandatory overhead and versioning.