Serializable Isolation
Also known as: serializability, SERIALIZABLE
Serializable isolation guarantees that concurrent transactions produce the same result as some serial execution of them. It is the strongest isolation level and the only one that eliminates all read and write anomalies — including write skew, which snapshot isolation permits.
Last reviewed · Part of the Architecture Glossary
In practice
The implementations differ enough to matter:
- Two-phase locking (2PL) — SQL Server, MySQL's SERIALIZABLE. Correct, and it blocks. Readers block writers.
- Serializable Snapshot Isolation (SSI) — PostgreSQL. Optimistic: transactions run at snapshot isolation, and the engine tracks read/write dependencies, aborting one transaction of any cycle it detects. Non-blocking, but your application must handle
40001 could not serialize accessby retrying. - Strict serializability — Spanner, FoundationDB. Serializable plus linearizable: the serial order also respects real time.
The application-level consequence of SSI is the part teams miss. Under Postgres SERIALIZABLE, retries are not an error-handling nicety; they are part of the contract. No retry wrapper means random user-facing failures under contention.
When it matters
Financial ledgers, inventory decrements, booking systems, anything with an invariant across rows that a constraint cannot express.
Common mistake
Assuming Oracle's and MySQL's "SERIALIZABLE" mean the same thing as PostgreSQL's. Oracle's SERIALIZABLE is snapshot isolation and permits write skew. Read the vendor's actual guarantee, not the keyword.
See also
- Snapshot IsolationSnapshot isolation gives each transaction a consistent view of the database as of its start time, so reads never block writes and writes never block reads.
- Write SkewWrite skew is the anomaly where two concurrent transactions each read an overlapping set of rows, each decides an invariant still holds, and each writes a different row — leaving the invariant violated.
- LinearizabilityLinearizability is the strongest single-object consistency model: every operation appears to take effect instantaneously at some point between its invocation and its response, and once a write is visible to any client it is visible to all.