Serializable Snapshot Isolation: True Serializability Without Heavy Locking

WHY IT EXISTS The strongest database guarantee, serializability, ensures transactions behave as if they ran one after another, preventing all concurrency bugs. Traditional methods to achieve this use heavy locking, which kills performance. Snapshot Isolation (SI) is fast but allows subtle bugs like write skew. Serializable Snapshot Isolation (SSI) was created to provide full serializability without the performance cost of locking.

THE MENTAL MODEL Think of SSI as optimistic concurrency with a referee. Transactions work in their own sandboxes (snapshots) and assume everything is fine. The database acts as a referee, watching what each transaction reads and what it plans to write. If it sees a situation where Transaction A's write might invalidate a decision Transaction B made based on an earlier read, it blows the whistle and aborts one of them. This prevents them from creating an inconsistent state that neither would have created alone.

HOW IT WORKS SSI extends Snapshot Isolation. Under standard SI, a transaction reads from a consistent database snapshot taken at its start. It can only commit if its writes don't directly conflict with other writes that have occurred since its snapshot was taken (a first-committer-wins rule). SSI adds a layer of dependency tracking. It detects when one transaction reads data that a second, concurrent transaction then writes to. If this creates a dangerous cycle of dependencies (a read-write conflict), SSI identifies the threat to serializability and aborts one of the transactions, forcing it to be retried.

WHEN TO USE IT Use SSI when you need the ACID serializability guarantee but your workload has many concurrent transactions and would suffer under traditional pessimistic locking. It is ideal for read-heavy workloads with infrequent write conflicts, where the cost of occasional retries is lower than the cost of constant locking. PostgreSQL uses SSI for its SERIALIZABLE isolation level.

WHEN NOT TO USE IT Avoid SSI in workloads with very high write contention. If transactions frequently conflict on the same data, the high rate of aborts and retries can become a performance bottleneck, potentially making pessimistic locking a better choice. Your application code must also be built to gracefully handle and retry aborted transactions.

ONE CANONICAL EXAMPLE Two on-call engineers, Alice and Bob, check a system to ensure at least one person is on duty. Alice sees Bob is on duty, so she signs off. Concurrently, Bob sees Alice is on duty, so he also signs off. With standard Snapshot Isolation, both transactions could commit, leaving no one on duty (a write skew anomaly). With SSI, the database would detect that Alice's decision (to write "Alice is off-duty") was based on a read that Bob's transaction invalidated. SSI would abort one of the transactions, forcing a retry and ensuring at least one engineer remains on duty.