Comparison
MVCCvsSnapshot isolation
MVCC
an update writes a new version of the row instead of overwriting it, so readers already in flight keep seeing the old one.
Keeping multiple versions of each row so that readers see the version valid for their snapshot rather than waiting on a lock. It is what makes concurrent reads cheap. The cost is garbage: dead versions accumulate and must be reclaimed, and a single long-running transaction can pin them all, bloating tables and slowing everything down.
Full entry →Snapshot isolation
your transaction sees the database frozen as of the instant it began, no matter what commits while it runs.
A level where every read comes from a consistent point-in-time snapshot, implemented with MVCC. Readers never block writers and writers never block readers, which is why it is the workhorse of modern databases. It still allows write skew, so it is not serialisable no matter what the level is named in your engine.
Full entry →