Two words, one letter apart in spirit, and yet they describe different promises. Teams often use them as synonyms in design reviews. Consequently, they sometimes pick a database that guarantees one property while the product quietly needs the other.
Two Communities, Two Words
First, a little history explains the confusion. Linearizability comes from the shared-memory and distributed systems world, introduced by Herlihy and Wing in 1990. Serializability comes from the database world, where it is the “I” in ACID. As Peter Bailis notes in Linearizability versus Serializability, these two traditions simply grew up apart.
Therefore, the terms describe different things. One is about single operations, while the other is about transactions.
Linearizability in Plain Words
Linearizability is a guarantee about single operations on single objects. Each operation appears to take effect at one instant between its start and its finish. Once a write completes, every later read must see it or something newer. In short, it respects the real-time order of events.
Notably, linearizability is local. You can check each object on its own, and combining linearizable objects stays linearizable. That makes it attractive for registers, locks and leader election.
Serializability in Plain Words
Serializability is about transactions, which group several operations over several objects. It says the outcome must match some one-at-a-time ordering of those transactions. However, the phrase “some ordering” matters. Serializability alone does not require that order to match the clock, and it is not composable.
As a result, a serializable system is allowed to place a transaction earlier than another one that finished before it started. Jepsen’s VoltDB analysis even points out that such systems may reorder write-only transactions far into the future.
Seeing the gap
The picture below shows the difference. Client A writes x = 1 and gets an acknowledgement. Later, Client B reads x and sees 0.
Strict Serializability: Having Both
Fortunately, you can combine the two. Strict serializability means transactions behave like a serial execution, and that order also matches real time. Jepsen describes it as a linearizable object whose state is the entire database. Moreover, Jepsen’s consistency map shows strict serializable at the top, implying both serializable and linearizable.
| Property | Linearizability | Serializability |
|---|---|---|
| Unit | Single operation | Transaction |
| Objects | One | Many |
| Ordering | Matches real time | Some serial order |
| Composable | Yes (local) | No |
| Home community | Distributed systems | Databases |
Keep the cost in mind, too. According to Jepsen, strict serializability cannot be totally available during a network partition. In a single-node database it is cheap, but across replicas it needs extra coordination, as this practitioner course explains.
What Serializable Actually Buys You
Now let’s test a promise in practice. Isolation names can mislead, so I ran the classic write-skew scenario on PostgreSQL 16.15. Two doctors are on call, and each transaction checks that at least two are on call before taking itself off. Together they would leave nobody on call. I ran 1,000 trials at each isolation level.
The result is stark. Under read committed and repeatable read, all 1,000 trials ended with nobody on call. Under serializable, none did, because the database aborted one transaction in every trial. In other words, you pay with aborts and must retry them. This kind of guarantee is also only as good as its implementation, so remember that Jepsen once reported serializability violations in PostgreSQL 12.3 under certain conditions. That link is a commentary blog, so check Jepsen’s own report for details.
Which word do you actually need?
- Locks, leader election or a single counter? You need linearizability.
- Multi-row invariants, like “at least one doctor on call”? You need serializability.
- Both, across replicas, such as money moving between accounts? Ask for strict serializability.
- Read the vendor’s documentation, since the default isolation level is rarely the strongest.
What We Have Learned
Linearizability and serializability answer different questions. Linearizability makes single operations on single objects respect real time, and it composes cleanly. Serializability makes multi-object transactions behave as if they ran one at a time, but in an order that need not match the clock. Strict serializability combines both, at a higher coordination cost. Our PostgreSQL test showed why the distinction matters: weaker isolation levels broke the invariant in every trial, while serializable protected it by aborting transactions. So name the guarantee you need, then verify what your database really provides.
