Физическое отличие READ_COMMITTED от SNAPSHOT
Если не влезать в дебри исходных текстов, то все достаточно просто. Транзакции имеют 4 состояния – active, committed, rolled back, in limbo (подробнее см. документ). Это состояние (2 бита) для всех существующих или завершенных транзакций (начиная с Oldest transaction) хранится на так называемых Transaction Inventory Pages (TIP) в базе данных.

При старте транзакций read_committed все они определяют "видимость" версий записей обращаясь к "глобальному" TIP – если версия записи committed, то ее можно читать. Если нет – нельзя.

При старте snapshot для транзакции делается "снимок" TIP. Т. е. он копируется локально для этой транзакции, и таким образом состояния транзакций "замораживаются" на момент старта этого snapshot. Именно поэтому snapshot "не видит" никаких, даже committed изменений, сделанных в БД после своего старта.

Понятно, что чем больше стартует транзакций в режиме snapshot, тем больше делается "локальных копий" TIP. С одной стороны, даже 200 тысяч транзакций займут примерно 50 килобайт (в одном байте помещается четыре двухбитовых "состояния" транзакции), то это не так страшно для современных серверов. Однако, на практике встречаются базы данных с гораздо большим числом транзакций в TIP (по разным причинам, в основном просто потому что не делается backup или не запускается sweep). В результате количество памяти, отводимое под локальный TIP для snapshot может оказаться большим. Кроме того, совершенно естественно, что время старта snapshot будет все дольше и дольше, чем больше состояний транзакций хранится в TIP (затраты времени на копирование страниц TIP в локальную копию TIP).