Snapshot Isolation

Snapshot isolation is a transaction isolation model in which each transaction reads from a consistent committed snapshot while write-write conflicts are rejected at commit. It is common in multi-version concurrency control systems because readers can proceed without blocking writers.

Snapshot isolation is stronger than reading whatever is newest at each statement, but it is not the same as serializability. It can still allow anomalies when two transactions read the same invariant and write different records.

Snapshot Read Rule

A transaction:

starts with snapshot timestamp:

Reads should see committed versions with commit timestamp:

and should not see later commits:

This gives the transaction a stable view even while other transactions continue writing.

Write Rule

The transaction writes a set:

of records, rows, keys or objects. At commit, the system checks whether another concurrent transaction already committed a write to the same item. A write-write conflict exists when:

Under first-committer-wins, one transaction commits and the other aborts or retries.

Read Set Limitation

Snapshot isolation does not necessarily validate every read predicate. A transaction can make a decision from read set:

while writing a disjoint set:

If another transaction does the same with a different write set, both may commit even though their combined effect violates an invariant. This is the write-skew failure mode.

Write Skew Example

Suppose an invariant requires:

Two transactions start from the same snapshot:

Transaction T_1 sets:

and transaction T_2 sets:

Their write sets are disjoint, so both can commit under snapshot isolation. The final state:

violates the invariant.

Version Retention

Long-running snapshots require old versions to remain available. If update rate is:

average retained version size is:

and the oldest active snapshot age is:

then retained version storage is roughly:

For:

the retained version storage is:

Long analytical reads can therefore become an operational risk for write-heavy systems.

Boundary With Serializability

Serializability requires the result to be equivalent to some serial execution. Snapshot isolation can be non-serializable because it may not catch predicate conflicts or write skew. Serializable snapshot isolation adds extra conflict tracking to reject histories that would form dangerous dependency cycles.

Snapshot isolation is still useful when read stability matters and known invariants are protected separately by constraints, materialized conflict rows, explicit locks, serializable transactions or application validation.

When It Fits

Snapshot isolation fits reporting queries, user workflows that need a stable view, read-heavy services, and transactions whose correctness is dominated by direct write-write conflicts. It is attractive when blocking readers behind writers would create unacceptable latency or operational coupling.

It is a weak fit when correctness depends on absence, counts, ranges, uniqueness across predicates, capacity constraints or “at least one must remain” invariants. In those cases the design should add serializable isolation, predicate locks, exclusion constraints, materialized guard rows, explicit distributed locks or an application-level validation step that runs at commit.

The user-facing contract should be precise. “Consistent snapshot” does not mean “globally latest”, and “repeatable reads” does not mean “serializable.” Documentation, monitoring and incident review should use the isolation term that the system actually enforces.

Boundary With Two-Phase Commit

Two-phase commit can coordinate an atomic commit across participants. Snapshot isolation defines what each transaction is allowed to observe and what conflicts cause abort. A distributed transaction can use both: snapshot reads for isolation and 2PC for atomic commit. Neither replaces the other.

Validation

Validation should include write-write conflicts, write skew, predicate reads, long snapshots, version cleanup, retry after serialization failure, distributed participants, failover during commit, stale read replicas, constraint enforcement and mixed isolation levels.

Useful evidence includes snapshot timestamp, commit timestamp, read set, write set, conflict check result, abort reason, retry count, retained-version size, oldest snapshot age, lock wait, deadlock count and invariant checks after concurrent workloads.

Failure Modes

Common failure modes include assuming snapshot isolation is serializable, missing predicate conflicts, allowing long snapshots to exhaust version storage, retrying non-idempotent transactions without a request key, mixing snapshot reads with external side effects, and validating only write-write conflicts while ignoring write skew.

A credible snapshot-isolation claim should state which invariants are protected by the database, which require explicit application design and what evidence proves that stale snapshots cannot make unsafe decisions.