What exactly does the SERIALIZABLE isolation level guarantee about a set of concurrent transactions, and why is the guarantee phrased as equivalent to some serial order rather than to the order in which they committed?
answer
- outcome == some serial execution
- reason about the transaction as if alone
- 'some' order, not commit order = engine freedom
- real-time order = strict serializability, stronger
- price paid in aborts, not in guarantees
basics
~20 sIt guarantees the committed result is identical to running the transactions one at a time in some order, with no overlap. The engine may pick any such order, so it can run them concurrently and only has to produce an equivalent outcome, not a specific one.
solid answer
~50 sSERIALIZABLE says: whatever concurrency actually happened, the committed outcome matches *some* serial execution of those transactions, one after another with no interleaving. That is the strongest practical correctness contract — it lets me reason about a transaction as if it ran alone, so any invariant I check inside the transaction still holds when I write. It is some order, not the commit order, for two reasons. First, it gives the engine freedom: it only has to produce an equivalent outcome, not enforce a particular sequence, so non-conflicting transactions proceed in parallel in any order. Second, requiring the real-time or commit order is a stronger property — strict serializability — that classical single-node SERIALIZABLE does not promise. The practical consequence: the engine may refuse to commit a transaction that would leave no valid serial order, so applications must handle serialization failures and retry.
go deeper
State the definition and the payoff: the result is as if the transactions ran one after another, so you can reason about yours in isolation.
Explain why some serial order gives the engine concurrency, and that the cost appears as blocking or serialization failures.
Distinguish it from strict serializability, note that the label may hide snapshot isolation, and describe what the application must do about aborts.
Position it as a correctness-versus-throughput decision and discuss which invariants deserve engine-enforced serial-equivalence versus constraints or design changes.
## The contract A schedule is the actual interleaving of operations from concurrent transactions. A schedule is **serializable** if its effect on the database, and the values the transactions read, are the same as those of *some* serial schedule — T1 fully, then T2 fully, or T2 then T1. SERIALIZABLE therefore promises: no anomaly of any kind. Not dirty reads, not non-repeatable reads, not phantoms, and not the subtler ones that have no ANSI name — the cases where two transactions each read a consistent view, each write something different, and jointly break an invariant neither could break alone. If a rule holds in every serial execution, it holds under SERIALIZABLE. That is why the level is developer-friendly: you can write a transaction as if it were the only thing running. Check a condition, act on it, commit. No revalidation, no explicit lock ordering, no defensive re-reads. ## Why some order **Freedom for the implementation.** If the standard demanded that the outcome match commit order, the engine would have to force transactions into that sequence — effectively serial execution. Demanding only equivalence to *some* serial order lets it run transactions in parallel and intervene only when the interleaving admits no valid order at all. Two transactions touching unrelated rows never conflict, so any order works and neither is delayed. **It is genuinely weaker than real-time order.** Consider T1 committing at 10:00:01 and T2 at 10:00:02, where the equivalent serial order the engine used is T2-then-T1. Classical SERIALIZABLE permits this: an outside observer who saw T1 commit first can still see results consistent only with T2 first. The stronger property that also respects real-time ordering is called **strict serializability**, and it is what distributed systems usually mean by strongly consistent. Single-node SQL SERIALIZABLE does not promise it, though in practice most single-node implementations rarely surprise you here. ## What it does not promise - **Not durability or atomicity** — those are separate ACID properties. - **Not that concurrent transactions all succeed.** Serial-equivalence is achieved partly by *refusing* schedules that cannot be untangled. A transaction may be aborted through no fault of its own, including a read-only transaction on some implementations. - **Not protection against logic outside the transaction.** If your application reads in one transaction, thinks, and writes in another, no isolation level can help — the two are separate points in the serial order. - **Not a cluster-wide guarantee.** Serializability is enforced by one engine over one database; a read on a replica or a value cached in the application is outside its scope. ## How it is achieved (brief) Two families dominate. **Locking implementations** use strict two-phase locking with predicate or range locks, so conflicting transactions block each other and the resulting schedule is serial-equivalent by construction; the residual failure mode is deadlock. **Optimistic implementations** let transactions run on snapshots, track read-write dependencies between them, and abort a transaction when the tracked dependencies show that no serial order exists; the residual failure mode is a serialization failure. Either way, the application-visible contract is the same, and so is the obligation: **be ready to retry**. ## A caution about the name Some products label as SERIALIZABLE a level that is really snapshot isolation — strong enough to remove dirty, non-repeatable and phantom reads, but not serial-equivalent. Before relying on the guarantee, check what your engine actually implements. The name in the SET TRANSACTION statement is not proof of the property. ## Answering well Define serial-equivalence in one sentence, give the practical payoff (reason about the transaction as if it ran alone), explain that some order buys the engine concurrency and is weaker than real-time ordering, and close with the price: some transactions will be aborted, so the level is only usable with a retry loop.
- If SERIALIZABLE removes every anomaly, why not run everything at that level?Because the guarantee is paid for with blocking or aborts. Locking implementations hold more and coarser locks, so contended workloads queue; optimistic implementations abort transactions when dependencies look dangerous, and the abort rate rises sharply with contention and transaction length. It also forces every application path to carry retry logic, which is a real engineering cost.
- Is SERIALIZABLE the same as strict serializability?No. Serializability requires the outcome to match some serial order; strict serializability additionally requires that order to respect real time — if T1 committed before T2 started, T1 must come first. Classical single-node SQL SERIALIZABLE promises only the former, which is why distributed systems use the stronger term when they mean externally consistent ordering.
A single-lane bridge would be commit-order enforcement; SERIALIZABLE is a multi-lane bridge that stops only the cars whose paths would actually cross, so long as the final traffic pattern could have happened one car at a time.
saying these in an interview costs you the question
- Saying transactions actually execute one at a time under SERIALIZABLE — they run concurrently; only the outcome must be equivalent.
- Claiming the equivalent serial order is always the commit order.
- Assuming the level makes every transaction succeed — it works partly by aborting some.
- Trusting the level name without checking whether the engine implements snapshot isolation under that label.
- Believing it protects logic split across two separate transactions.