The question this answers
My database says it is serializable. Does that mean a read always sees the latest committed write?
Serializability: the outcome of executing a set of transactions is equivalent to executing them one at a time in *some* serial order. That order is unconstrained by real time. Linearizability: each single operation on a single object appears to take effect at an instant within its own interval, and that instant respects real time. Strict serializability is the conjunction: some serial order, and that order is consistent with real time.
Everything below is bought to hold this sentence. "Strongly consistent" with no scope attached is a slogan, not a guarantee — read what it actually covers, and what it explicitly does not.
A node executing a transaction knows the versions it read and the locks or timestamps it holds. Serializability can be enforced locally by a single-node concurrency-control mechanism — it needs no notion of global time. Linearizability cannot, because it constrains order against real time, which no node can observe. That asymmetry is why a single node is trivially strictly serializable and a cluster is not.
A node knows its own state and the messages that arrived. Everything else is inference from evidence that was already stale. "B has not replied in five seconds" is knowledge; "B is down" is a decision — and usually the bug.
The definitions, stated so they cannot be blurred
Serializability is a transaction isolation property. Take a set of transactions, each of which may read and write many objects. The execution is serializable if its outcome could have been produced by running those transactions one after another in *some* order. Which order? Any order. The definition does not care whether that order matches the order in which the transactions actually happened.
Linearizability is a recency property of individual operations on a single object. It says each operation appears to take effect at a point inside its own interval, and that if operation A finished before operation B started, A's effect point precedes B's. It says nothing about grouping operations into transactions, because it has no concept of a transaction.
Once stated side by side the orthogonality is obvious. One is about *atomicity of groups*; the other is about *ordering against wall-clock reality*. They constrain different things, and a system can satisfy either without the other.
| Not linearizable | Linearizable | |
|---|---|---|
| Not serializabletypical | Most default database configurations: read-committed isolation with reads served from a replica. Very common. | A linearizable key-value store with no transactions — etcd, ZooKeeper, single-key operations in most distributed KV stores. |
| Serializableprotocol | A serializable database whose reads may be served from a lagging replica, or one that assigns commit timestamps without a real-time constraint. Every transaction is equivalent to some serial order — just not necessarily one matching real time. | Strict serializability: transactions are equivalent to a serial order *and* that order respects real time. This is what Spanner-class systems and single-node databases provide. |
The anomaly serializability permits and people do not expect
Here is the case that makes the distinction concrete. Transaction T1 commits at 10:00:00, writing x = 1. Transaction T2 begins at 10:00:05, reads x, and returns 0. Is that serializable? Yes — the serial order T2, T1 explains it perfectly. Both transactions are atomic, neither saw a partial state, and the outcome equals a serial execution.
Is it what anyone wanted? No. A user who committed a change five seconds ago and then read it back got the old value, and the database is entirely within its rights. Serializability alone permits an arbitrarily stale but internally coherent view. In practice a single-node database never exhibits this because its natural implementation orders transactions by their real execution, but a distributed one absolutely can, and several do at their "serializable" level.
Conversely, a linearizable store forbids exactly this anomaly for a single key and gives you no atomicity at all across keys. Transferring a balance between two accounts on a linearizable KV store is two separate linearizable operations, and a reader can observe the state between them. Each operation is perfectly ordered; the invariant is still violated.
Why the distinction changes what you buy
The practical consequence is that "serializable" and "linearizable" answer different questions, so a requirement must be assigned to the right one. Does my multi-step operation see a coherent state and leave one behind? That is serializability, and no amount of linearizability provides it. Does my read reflect what already finished? That is linearizability, and no amount of serializability guarantees it.
Cost differs too, and not in the direction people assume. Serializability can be provided by a single node with no distributed coordination whatsoever — a laptop's Postgres is serializable. Linearizability in a distributed system requires cross-node communication on every operation. So a serializable-but-not-linearizable distributed database can be substantially cheaper than a linearizable key-value store, despite "serializable" sounding stronger.
The Database domain owns transactions, isolation levels and the anomalies each level permits — see dbLinks transactions-and-acid and isolation-levels. What belongs here is only the boundary: which of the two properties your distributed design actually needs, and the fact that the strongest useful combination is strict serializability, whose price is both the transaction machinery and the cross-node coordination.
- Need multi-object atomicity → serializability. Linearizability will not give it to you.
- Need "my read sees what already committed" → linearizability (or strict serializability if transactions are involved).
- Need both → strict serializability, and expect to pay coordination on every transaction.
- Snapshot isolation is neither: it is not serializable (write skew survives) and not linearizable (the snapshot may be stale). It is nonetheless the default in many databases.
Key points
- Serializability: equivalent to *some* serial order of transactions. Real time is not constrained.
- Linearizability: single operations on a single object, ordered consistently with real time.
- They are orthogonal. Neither implies the other, and all four combinations exist in shipping systems.
- Strict serializability is the conjunction, and is what most people mean by either word.
- Serializability is achievable on one node with no distributed coordination; linearizability in a cluster is not.
The chain, answered
Every field here is required, which is why no lesson in this domain can recommend a design without naming what an operator sees when it fails, what survives the partition, what repairs it afterwards, and the simpler thing to consider first.
- • Serializability is enforced by a concurrency-control mechanism: two-phase locking, serializable snapshot isolation, or deterministic ordering.
- • The mechanism produces a serialization order — an ordering of transactions the execution is equivalent to.
- • Linearizability is enforced by ensuring every operation observes the effects of all operations that completed before it began, which requires the serving node to rule out a newer state elsewhere.
- • Strict serializability requires the serialization order to also be consistent with real time, which means commit timestamps must be comparable across nodes — the reason systems reach for tightly bounded clocks or a central sequencer.
- • Verification differs: serializability is checked by looking for a cycle in the dependency graph; linearizability is checked by searching for an effect-point placement.
- • A distributed database assigns commit timestamps without a real-time constraint, producing serializable but stale-looking results.
- • Reads are routed to a replica, so even a serializable engine returns a stale snapshot.
- • A team uses a linearizable key-value store for a multi-key invariant and observes intermediate states.
- • Snapshot isolation is mistaken for serializability and write skew corrupts an invariant that spans rows.
- • Clock uncertainty makes strict serializability unachievable, and the system silently provides serializability instead.
- • Write skew on snapshot isolation: two transactions each check "at least one doctor is on call", each sees two, each removes a different one, and the ward is left uncovered. The operator sees an invariant violation with two clean, committed transactions in the log.
- • Stale read at serializable isolation: a user commits and immediately re-reads through a different connection, getting the previous value. Serializable, correct by the definition, and reported as a data-loss bug.
- • Torn multi-key update on a linearizable KV store: a reader observes the state between two individually-linearizable writes. Observed as a balance that momentarily does not sum, or an item briefly in two lists.
- • Vendor-label mismatch: a system documented as "serializable" turns out to provide snapshot isolation under that name, and the team's invariant depended on the difference. Discovered via corrupted data, not via an error.
- • Coordination-cost surprise: enabling strict serializability across regions raises transaction latency to the inter-region round trip, and throughput collapses because contended transactions now hold their conflicts for that duration.
- • Serializability requires coordination between conflicting transactions only — non-conflicting ones proceed independently, which is why it scales better than intuition suggests.
- • Linearizability requires coordination on every operation, including reads, because a read must rule out a newer state anywhere.
- • Strict serializability requires both, plus a way to compare commit times across nodes — a central sequencer, a bounded-uncertainty clock, or a consensus-ordered log. See Total Order Broadcast Is Consensus Wearing a Different Hat.
- • A partition makes strict serializability unavailable on the minority side, exactly as linearizability is.
- • Serializability alone can survive a partition on both sides *if* each side handles a disjoint set of data; it cannot if transactions span the divide.
- • Systems commonly degrade from strict serializability to serializability, or from serializable to snapshot isolation, under load or failure — and rarely say so.
- • Detect: test for the specific anomalies rather than trusting the isolation-level name. Write skew and stale-read tests are short and decisive.
- • Contain: if the guarantee degrades under failure, make the degradation explicit and refuse the operations that depend on the stronger level.
- • Recover: no data recovery is needed for a correctly-implemented weaker level; recovery is needed for invariants your application violated while assuming a stronger one.
- • Reconcile: invariant-repair jobs for the specific rules that write skew or stale reads could have broken — the database cannot infer these.
- • Verify: continuous invariant assertions over the data, since they catch level mismatches that documentation review does not.
- • The isolation level actually in force per transaction, which is frequently not the one configured at the cluster level.
- • Serialization-failure and retry rates, which are the visible cost of genuine serializability under contention.
- • Whether reads are served at a snapshot and how old that snapshot is.
- • Invariant-violation counters for the specific multi-row rules that snapshot isolation does not protect.
- • Transaction latency broken down by whether cross-region coordination was required.
- • Any conversation about what a distributed database provides, where the two words are used interchangeably and should not be.
- • Designing an invariant that spans rows or services, where picking the wrong property means buying the wrong guarantee.
- • Evaluating a vendor claim, since the four-cell matrix is the fastest way to find out what is actually on offer.
- • Single-node systems, which are strictly serializable by construction and where the distinction is academic.
- • Systems with no multi-object invariants, where linearizability per key is the whole requirement and transactions add cost for nothing.
- • Design the invariant into a single object so per-object linearizability suffices — putting the whole aggregate in one row or one document is often the cheapest correctness win available. See Start From the Invariant, Not From the Architecture.
- • Accept snapshot isolation and add explicit locking for the specific invariants it does not protect.
- • Use sagas with compensations where a distributed transaction is not available. See Sagas: Trading Isolation for Availability and A Refund Is Not a Rollback.
- • Restructure so the operation is commutative and needs neither property. See Coordination Avoidance: Restructuring the Problem Instead of Paying for It.
Serializable and linearizable are not two strengths of one thing
| Serializability | Linearizability | |
|---|---|---|
| Unitprotocol | A transaction: a group of operations | One operation on one object |
| Constrainsprotocol | Equivalence to some serial order | An effect point inside the interval, ordered by real time |
| Real timeprotocol | Not constrained at all | The whole point |
| Achievable on one node?protocol | Yes — local concurrency control suffices | Trivially, because one node is the real-time order |
| Achievable in a cluster?assumption | Yes, without distributed time | Only with coordination on every operation |
| Survives a partition?assumption | On the side that holds the data | Not on the minority side |
Search exhausted after 2 states: no placement of effect points inside the operations' intervals produces a legal sequential history that also respects real-time order. The search could never place T2 (read-only txn)'s read: it observed 0 at a point where the register necessarily held 1.
What people believe, and what is true
Serializable means my read sees the latest committed data.
It means the outcome matches *some* serial order. A transaction that begins after another committed may still be ordered before it, and returning the old value is permitted. Only "strict" adds the real-time constraint.
Linearizable means my transactions are safe.
Linearizability has no concept of a transaction. Two linearizable writes to two keys are two independent operations and a reader can see the state between them.
Serializable is stronger than linearizable.
Neither is stronger; they constrain different things. Their conjunction, strict serializability, is stronger than both.
Snapshot isolation is basically serializable.
Write skew is permitted under snapshot isolation and forbidden under serializability, and write skew is exactly the anomaly that breaks "at least one of these must remain true" invariants.
Go deeper
Only the levels this lesson can honestly fill — a missing level is a claim nobody had.
Overview
Serializability: transactions look like they ran one at a time, in some order. Linearizability: single operations respect real time. Different properties; strict serializability is both.
Practical
Assign each requirement to the right property. Multi-object atomicity is serializability. "See what already committed" is linearizability. If you need both, you are buying strict serializability and its cross-node coordination on every transaction. And test your database for write skew rather than trusting its isolation-level label.
Advanced
Serializability is checked by finding the dependency graph acyclic; linearizability by finding an effect-point placement. The two verification problems have different shapes because the properties do. Note also that linearizability is *composable* (a system of linearizable objects is linearizable) while serializability is not (composing two serializable systems is generally not serializable), which is precisely why cross-service transactions are hard and why sagas exist. See Atomicity Stops at the Process Boundary and Two-Phase Commit: Buying Atomicity With a Promise.
Apply it
- 🔧 Construct a write-skew scenario for an invariant in your own system, then determine empirically whether your database's default isolation level permits it.
- 💬 Give a history that is serializable but not linearizable, and one that is linearizable but not serializable.
- 💬 Your database is at serializable isolation and a user reports reading a stale value moments after committing. Is that a bug?
- 💬 You have a linearizable key-value store and need to move an item atomically between two lists. What do you actually need?