Two Models, Two Guarantees: Serializability for Isolation, Linearizability for Consistency
How do modern databases and distributed systems ensure correctness while allowing operations to run concurrently? Two foundational guarantees — serializability and linearizability — offer different answers depending on whether you care about logical correctness or real-time visibility. In this post, we’ll explore what they are, how they differ, and why it’s crucial not to confuse them.
Serializability
Serializability is a concurrency control property that ensures concurrently executing transactions produce a result that is equivalent to some serial (one-at-a-time) execution of those transactions.
In practice, transactions often execute concurrently, and their internal operations (such as reads and writes) may interleave, potentially leading to concurrency anomalies such as lost updates, dirty reads, or write skew. However, conflicting operations—for example, two transactions writing to the same data item—are resolved by enforcing a logical ordering that preserves the illusion of isolated execution.
This means that although transactions are not physically isolated (since operations may overlap in time), the system guarantees that each transaction appears to run in complete isolation from others. As a result, the final state of the system is indistinguishable from one that would have been produced by executing the transactions sequentially in some order.
Take for example a bank scenario with three accounts: X, Y, and Z.
Initial balances: X = 100, Y = 200, Z = 300
Transactions:
T1 comprises following operations:
(T1) X = X - 10
(T1') Y = Y + 10
T2 comprises following operations:
(T2) Y = Y - 5
(T2') Z = Z + 5
A non-serializable execution would look like:
T1 executes first:
(T1) X = 100 - 10 = 90
(T1') Y = 200 + 10 = 210
T2 executes independently (as if unaware of T1):
(T2) Y = 200 - 5 = 195
(T2') Z = 300 + 5 = 305
Results in X = 90, Y = 195 (incorrect), Z = 305
Since, T1' write to Y and T2 read to Y are not ordered, this leads to inconsistent interleaving. This is a classic example of a lost update anomaly, where the update performed by T1' is effectively overwritten and lost due to the concurrent execution.
If these transactions had been physically isolated (i.e., executed one after the other without overlap), we would see one of two valid serial schedules:
T1 → T2:
T1 executes first:
(T1) X = 100 - 10 = 90
(T1') Y = 200 + 10 = 210
T2 executes second:
(T2) Y = 210 - 5 = 205
(T2') Z = 300 +5 = 305
Resulting in X = 90, Y = 205, Z = 305
Or, T2 → T1:
T2 executes first:
(T2) Y = 200 - 5 = 195
(T2') Z = 300 +5 = 305
T1 executes second:
(T1) X = 100 - 10 = 90
(T1') Y = 195 + 10 = 205
Resulting in X = 90, Y = 205, Z = 305
Now consider the following example of a valid serializable execution, where transactions are not physically isolated and their operations interleave, yet the final outcome remains consistent with some serial schedule:
Case 1: Equivalent to serial schedule T2 → T1
(T1) X = 100 - 10 = 90
(T2) Y = 200 - 5 = 195
(T1') Y = 195 + 10 = 205
(T2') Z = 300 + 5 = 305
Resulting in X = 90, Y = 205, Z = 305
Case 2: Equivalent to serial schedule T2 → T1
(T2) Y = 200 - 5 = 195
(T1) X = 100 - 10 = 90
(T2') Z = 300 + 5 = 305
(T1') Y = 195 + 10 = 205
Resulting in X = 90, Y = 205, Z = 305
Serializability is considered the gold standard of isolation in databases. It defines how transaction operations may execute concurrently while ensuring that the final outcome is equivalent to some serial (i.e., one-at-a-time) execution of those transactions.
A key property of serializability is that the specific execution order of logically isolated transactions is irrelevant — as long as their effects do not interfere in a way that violates serial equivalence. In essence, isolation in ACID refers to ensuring that concurrent transactions do not observe each other’s intermediate states. It does not require any specific ordering of transactions with respect to real time. While ordering may relate to consistency, it is not a requirement for isolation.
Consistency (the “C” in ACID) refers to preserving database invariants (e.g., constraints, integrity rules). Achieving consistency might involve enforcing a certain order of operations, particularly if your logic depends on it. For example, consider following two concurrent transactions:
T1: Transfers £100 from Account A to B
T2: Applies 10% interest to Account B
If T2 runs before T1, it may apply interest before the transfer — a different result than if it ran after. That’s a consistency issue, because ordering affects correctness.
But from an isolation point of view, as long as neither transaction sees intermediate state from the other, isolation is maintained.
According to the ACID model, as defined on Wikipedia:
“Isolation ensures that concurrent execution of transactions leaves the database in the same state that would have been obtained if the transactions were executed sequentially.”
This naturally raises an important question:
Why are “serializability” and “isolation” treated as distinct concepts, even though they seem to describe the same idea of preventing interference between transactions? If serializability ensures isolated behavior, why not just refer to it as isolation?
The answer to this is straightforward:
Isolation is a property in the ACID model while serializability is the strongest level of isolation. There are other weaker forms of isolation: Read Committed, Repeatable Read, Snapshot Isolation. While all serializable executions are isolated, not all isolation levels guarantee serializability.
Serializability being the strongest level of isolation addresses not only lost updates but also all the other anomalies:
| Anomaly | Serializability’s Solution |
|---|---|
| Dirty Read | Reads see only committed data (no uncommitted values). |
| Dirty Write | Writes are ordered; no overwriting uncommitted data. |
| Lost Update | Conflicting writes are serialized (e.g., via locks). |
| Non-Repeatable Read | Locks or MVCC snapshots freeze read data. |
| Phantom Read | Predicate locks block inserts matching queries. |
| Read Skew | Transactions see a frozen snapshot of all data. |
| Write Skew | Conflicts are detected (e.g., via SSI). |
Most modern databases that offer serializability rely on one of three core techniques:
- Serial execution — running transactions one at a time in a strict sequence
- Two-Phase Locking (2PL) — coordinating access to shared data through a locking protocol
- Optimistic Concurrency Control — techniques such as Serializable Snapshot Isolation (SSI), which allow transactions to proceed concurrently and validate serializability at commit time
Another important property of serializability is that its scope extends to multi-object, multi-operation transactions because such transactions are prone to interleaving anomalies, making serializability checks critical.
It is worth noting that serializability is not restricted to single-node or purely database contexts; it is a general-purpose model of concurrency correctness applicable across distributed systems as well.
Linearizability
Linearizability guarantees that distributed operations (e.g., reads/writes in a replicated system) appear instantaneous and respect real-time order.
It is a correctness condition for consistency in distributed systems. All observers must see a consistent view of the system as if there were no replication or concurrency. The basic idea is to make a system appear as if there were only one copy of the data, and all operations on it are atomic. In other words, it is a global consistency model. It applies across multiple nodes or devices and ensures that all operations appear to occur atomically and in real-time order. Once a read returns a particular value, all later reads should return that value or the value of a later write.
If serializability governs how concurrent transactions interleave, ensuring logical correctness, linearizability governs how operations appear across distributed replicas, ensuring real-time consistency. Each plays a foundational role in its domain — concurrency control and consistency models, respectively.
To give an example,
(A) Write-Read Linearizability
Scenario: A distributed key-value store with nodes across the world.
• At 10:00:01, client A writes x = 5 to the system.
• At 10:00:02, client B reads x and must get 5 (since it happened after A’s write) even if query is made to any of the replicas.
Linearizability guarantees that every read sees the most recent write, based on actual real-time.
(B) Write-Write Linearizability
Scenario: Let a distributed key-value store maintain a balance for account A.
T1: A.deposit(100)
T2: A.withdraw(50)
Linearizable Behavior: If transaction T1 completes before T2 is invoked (per wall-clock time), then T2 must reflect the effect of T1. That is, T2 must observe a balance of at least 100, and the withdrawal of 50 should succeed.
Non-linearizable Behavior: If T2 fails with an “insufficient funds” error, despite being invoked after the successful completion of T1, the system violates linearizability. This scenario implies that T2 did not observe the effect of T1, violating the real-time order and atomic visibility guarantee.
It is important to note that unlike serializability whose scope extends to multi-object, multi-operation transactions, linearizability is a guarantee about single operations on single objects. It provides a real-time (i.e., wall-clock) guarantee on the behavior of a set of single operations (often reads and writes) on a single object (e.g., distributed register or data item).
In the context of the CAP theorem, linearizability represents a strong consistency model — ensuring that all operations appear to occur in a real-time global order.
While it plays a key role in reasoning about distributed systems (e.g., databases and caches), it should not be confused with the “Consistency” in ACID, which refers to ensuring that a database moves from one valid state to another, maintaining integrity constraints such as foreign keys, uniqueness, or balance ≥ 0. This notion of consistency in ACID is focused on application-level correctness, not on the visibility or ordering of operations.
Going back to our bank scenario example of valid serializable order of execution of operations:
Case A: Equivalent to serial schedule T2 → T1
(T1) X = X - 10 = 100 - 10 = 90
(T2) Y = Y - 5 = 200 - 5 = 195
(T1') Y = Y + 10 = 195 + 10 = 205
(T2') Z = Z + 5 = 300 + 5 = 305
We could argue that since T1' (Y = Y + 10) is expected to see the value of Y written by T2 (Y = Y - 5), isn't this possible only when T2 write and T1' read are linearizable?
Serializability ensures correctness at the transaction level, not at the operation level.
The final outcome must match some serial schedule. But it does not say that the schedule must follow real-time order. In fact, it’s fine if T1' (Y = Y + 10) runs before T2 (Y = Y - 5) in real-time, as long as the overall result is explainable by some serial ordering.
Case B: Equivalent to serial schedule T1 → T2
(T1) X = X - 10 = 100 - 10 = 90
(T1') Y = Y + 10 = 200 + 10 = 210
(T2) Y = Y - 5 = 210 - 5 = 205
(T2') Z = Z + 5 = 300 +5 = 305
So in a serializable system, T1' may or may not see T2’s write (as in Case A), depending on the ordering that the database chooses internally for serializability.
Linearizability, in contrast, enforces real-time visibility. If T2 finishes before T1' starts, then T1' must see T2’s write. So only linearizability guarantees visibility according to real-time.
Evidently, linearizability is stronger guarantee than serializability.
It guarantees two key properties:
- All operations appear as if they occurred in some serial order
- That order respects real-time — if operation A completes before B begins in wall-clock time, A must appear before B.
This means any system that is linearizable is, by default, also serializable — because it’s already ensuring a valid serial execution. In other words, linearizability implies serializability. However, the same not true other way around, serializability does not imply linearizability.
It is worth mentioning here that serializability when combined with linearizability yields a stronger guarantee known as strict serializability. This model implies both logical isolation (from serializability) and real-time consistency (from linearizability) for distributed transaction operations.
In fact, linearizability can be seen as a special case of strict serializability, where transactions are limited to single operations on single objects.
Conclusion
That's all for this post. I hope this attempt to clear the fog around these two often-confused models — serializability and linearizability — was worth your time.
Together, both serializability and linearizability shape how we reason about concurrent execution, whether within a single-node transactional database or across a globally distributed system. Choosing between them — or combining them via strict serializability — depends on your system’s correctness requirements, performance constraints, and tolerance for anomalies.
By grasping these foundational models, you gain the vocabulary and tools to evaluate the guarantees your system truly provides — and more importantly, what it doesn’t.
References