Linearizability, serializability, and snapshot isolation explained
Compare single-object real-time order, transaction order, strict serializability, snapshot isolation, write skew, and model relationships.
The whole story in 6 lines
Compare linearizability, serializability, strict serializability, and snapshot isolation using the histories and anomalies each one permits.
- A consistency model defines which concurrent histories a system allows and which outcomes clients may safely rule out.
- Linearizability gives each single-object operation one real-time point between invocation and response.
- Serializability makes committed transactions equivalent to some serial order without requiring that order to match wall time.
- Strict serializability combines serial transaction order with the real-time order clients observed.
- Snapshot isolation gives each transaction a stable snapshot and rejects write conflicts, but it can still permit write skew.
- Linearizability and serializability constrain different scopes, while strict serializability combines both requirements.
Setup
Alice finishes a database write, but Bob immediately reads the old value. Both requests succeeded, which creates a mystery about the outcomes a database may return. Consistency models answer that practical problem. Let us start with four words we need to compare their promises.
An operation is a single read or write of one key. A transaction is a group of operations that should logically happen together. The difference matters: linearizability talks about operations, serializability talks about transactions.
An anomaly is an outcome the database should not produce under a particular promise. A stale read is one example. We compare consistency models by asking which anomalies each promise rules out and which outcomes it still allows.
Real-time order follows the wall clock. If transaction A finishes before transaction B starts, A came first in real time. Some guarantees preserve that fact while others only constrain different relationships. These four terms now give us enough language to begin.
Over the next six stages we will build up the picture: why models exist, then linearizability, serializability, strict serializability, snapshot isolation. And finally the lattice that ranks them all. Let us begin with the most basic question: what goes wrong without rules.
Why models exist
Here is the setup. There is one logical key x. The database stores three copies on three replicas. Alice and Bob are two clients sending requests. They have no idea where their requests land.
Alice writes x equals 1 to replica R1. R1 acknowledges. As far as Alice knows, the write is done. The system told her so.
A moment later, Bob reads x from replica R3. R3 has not received the new value yet. So Bob gets x equals 0. The old value. After Alice already heard the write succeeded.
This is a stale read anomaly. The write now waits for every replica before acknowledging, and Bob always sees the new value. That is the contract changing under your feet.
Without a written rule, the database is allowed to give either answer. Stale reads, lost writes, ghost values, all of it is legal until you pick a model that forbids it. That is what a consistency model does. The next four stages each forbid something different.
Linearizability
Without a stronger rule, Bob can read stale values. Linearizability fixes this for a single key by placing each operation at one point between invocation and response on the real-time timeline.
Operation A is Alice writing x equals 1. The bar shows when Alice sent the request and when she got the acknowledgment. The dot inside the bar is the linearization point: the moment the write actually took effect.
Operation B is a read by Bob that overlaps Alice's write in real time. Because the operations overlap, the database has freedom. Bob is allowed to see either 0 or 1. Both are linearizable.
The stage has reached the decision that determines its next state. What extra order does linearizability preserve for completed operations?
That is the rule in one line: once a write completes, every read that starts later must see that value or a newer one. The system behaves as if there were one global copy and operations took turns touching it.
But linearizability only talks about one key at a time. It says nothing about what happens when a transaction touches multiple keys. For that we need a different model. Next up: serializability.
Serializability
Linearizability constrains operations on one object, while applications also need multi-operation transactions. Transactions T1 and T2 each touch two keys and must still correspond to some serial order.
In the actual execution, the operations are interleaved. T1 reads x. T2 reads y. T2 writes y, which completes this part of the mechanism. T1 writes x. Reads and writes are tangled across both transactions.
Serializability asks: is this tangle equivalent to running the transactions one after another in some order. If yes, the schedule is serializable. The database is allowed to do this.
On the right we show the equivalent serial order: T2 ran fully, then T1 ran fully. Every key ends up with the same value as the interleaved version.
Here is the catch. Notice that T1 actually started first in real time. But the database is claiming T2 happened first. That is allowed. Serializability does not require the serial order to match the wall clock.
So serializability protects against multi-key anomalies inside transactions, but it can still violate real-time ordering across transactions. To get both, we need a stronger model. That is strict serializability. Next stage.
Strict Serializability
We just saw serializability allows the database to reorder transactions across the wall clock. That feels wrong if you watched T1 commit before T2 even started. Strict serializability is the fix.
Look at the wall clock at the top. T1 starts, runs, commits. Then T2 starts, runs, commits. In real time, T1 is clearly first. No overlap.
Plain serializability would let the database claim the equivalent serial order is T2 then T1, as long as the end state matches. That is the schedule on the left. Legal under serializable.
Strict serializability adds one more rule: if T1 committed before T2 began, the serial order must put T1 first. The schedule on the right is the only valid one.
You can think of strict serializability as serializability plus linearizability. Multi-key transactions that also respect real-time order. This is what Google Spanner promises with its TrueTime clocks.
But strict serializability is expensive. Most databases settle for something weaker. The most popular weaker model is snapshot isolation, and it has a famous failure mode. We see it next.
Snapshot Isolation
★ If you remember one thing · Snapshot Isolation can allow two disjoint writes that violate a shared invariant, while serializability must reject one.
The setup is the doctors-on-call problem. Hospital rule: at least one doctor must stay on call. Right now Alice and Bob are both on call. Two doctors, rule satisfied.
Alice and Bob both want to take themselves off call. They each open a transaction at the same time. SI gives each transaction its own frozen snapshot of the database.
Alice's transaction reads the on-call list. She sees two doctors: herself and Bob. She thinks: it is safe to take myself off, Bob will still be on call.
The stage has reached the decision that determines its next state. Which model must reject this write-skew history?
Alice writes alice.on_call equals false. Bob writes bob.on_call equals false. Different keys. SI's first-committer-wins rule only catches conflicts on the same key. Both transactions commit successfully.
Switch the Mode control through every choice. Compare the downstream outcome while the earlier input and system boundary remain fixed.
This is write skew. It is why people who say snapshot isolation is close enough to serializable are wrong. Same-key conflicts are caught. Cross-key invariants are not. Now let us put all four models on a single map.
The lattice
Let us map the promises by two properties: ordering a whole transaction and respecting completed real time. Linearizability and serializability cover different halves, while strict serializability combines both.
Snapshot Isolation sits below serializability on the transaction side because write skew is allowed. Notice that linearizability is a sibling, not another rung below strict serializability. It protects one object with real time instead.
The first history pin is a read that begins after a write finishes but still returns the old value. A single-object real-time promise must reject that history, so its path reaches linearizability and strict serializability.
The second pin is a transaction cycle that cannot match any one-at-a-time order. Serializability and strict serializability reject it because both require a valid serial transaction history.
The third pin is the write-skew history we just built. Snapshot Isolation permits both disjoint commits, but serializability and strict serializability must stop that outcome.
The completed map reveals the key relationship. Strict serializability combines transaction ordering with completed real-time order, while linearizability and serializability remain incomparable outside that combination.
Choose a guarantee by naming the histories your application cannot tolerate, then verify that the database actually rejects them. Now let us reconnect every promise in the recap.
Recap
We started by asking why isolation models exist. Without rules, two clients reading the same key can see different values. The replicas drift, and every weird answer is technically allowed.
Linearizability fixed that for a single key. Once a write completes, every later read must see that value or a newer one. The system pretends one global copy exists. Single-key, real-time.
Serializability handled multi-key transactions. The interleaved execution must be equivalent to some serial order. But it does not require that order to match the wall clock. Multi-key, no real-time.
Strict Serializability combined both. Multi-key transactions plus real-time order. The gold standard. Spanner-grade. The price is coordination, often using physical clocks bounded by hardware.
Snapshot Isolation gave us a popular weaker model. Each transaction reads from a snapshot. Conflicts on the same key abort. But cross-key invariants can break, the doctors-on-call write skew problem.
Together these models form a lattice. Stronger means more forbidden and more expensive. Weaker means faster but the application must reason about more anomalies. Look at all five together. Each one defeats a different kind of bug.
The takeaway in one sentence: linearizability is about single-key real-time order, serializability is about multi-key serial equivalence, strict serializability combines both. And snapshot isolation is the popular shortcut that misses write skew. You will never confuse these terms again.
The whole story in 6 lines
Compare linearizability, serializability, strict serializability, and snapshot isolation using the histories and anomalies each one permits.
- A consistency model defines which concurrent histories a system allows and which outcomes clients may safely rule out.
- Linearizability gives each single-object operation one real-time point between invocation and response.
- Serializability makes committed transactions equivalent to some serial order without requiring that order to match wall time.
- Strict serializability combines serial transaction order with the real-time order clients observed.
- Snapshot isolation gives each transaction a stable snapshot and rejects write conflicts, but it can still permit write skew.
- Linearizability and serializability constrain different scopes, while strict serializability combines both requirements.