Snapshot isolation

A transaction reading a snapshot need not immediately observe later concurrent commits. Multiversion storage retains required older versions so the transaction can continue querying its chosen view rather than receiving a new committed view for every statement.

PostgreSQL 18 describes its Repeatable Read implementation as snapshot isolation. The snapshot begins with the first non-transaction-control statement, while queries still see the transaction’s own earlier changes. Exact snapshot timing remains a product-specific contract.

References: [1] [2]

A snapshot does not authorize arbitrary overwriting of old data. Under this PostgreSQL level, attempting to modify a row changed by a concurrent committed transaction can produce a concurrency failure requiring restart.

Two transactions can instead read related data and write different records, avoiding a direct write-write conflict while producing an outcome with no valid serial explanation. PostgreSQL’s example computes group sums and inserts into the other group, illustrating a serialization anomaly despite stable snapshots.

References: [1]

SQL isolation-level names specify minimum protections that do not identify every product’s implementation. PostgreSQL notes that other systems can offer Repeatable Read and Snapshot Isolation as distinct levels, so they are not universally interchangeable names.

Serializability additionally requires preventing or detecting dependencies inconsistent with a serial execution. PostgreSQL Serializable adds monitoring over similar snapshots and can abort a transaction. That is an extra correctness condition, not a property obtained simply by retaining a snapshot longer.

References: [1]