A Consistent Snapshot
Snapshot isolation, or SI, gives a transaction a view of the database frozen at the moment it began. Every read sees the data as it was committed at that instant, regardless of changes committed afterward by others. It is naturally built on MVCC.
What It Prevents
Because reads come from a stable snapshot, SI prevents dirty reads, nonrepeatable reads, and read skew. A transaction never sees a value flicker mid run, which makes reasoning about reports and consistency checks far easier.
First Committer Wins
For writes, SI uses a first committer wins rule. If two transactions modify the same row concurrently, the first to commit succeeds and the second is aborted with a write conflict. This blocks the classic lost update on a single row.
Not Quite Serializable
SI is strong but not fully serializable. Because each transaction reads its own snapshot and only write write conflicts on the same row are caught, it permits write skew, where two transactions read overlapping data and write different rows, together violating a rule neither broke alone.
Key idea
Snapshot isolation reads from a frozen start time snapshot and resolves same row write conflicts by first committer wins, but is weaker than serializable because it allows write skew.