In my previous blog, I explored how serializability ensures isolation across transactions while linearizability guarantees real-time consistency of single objects.
This post builds on that discussion by diving deeper into serializability itself. Concurrency control in databases is all about ensuring that transactions running in parallel behave as if they had been executed one after the other. This property is called serializability, and it’s the gold standard for correctness.
But not all forms of serializability are created equal. Two of the most commonly discussed are conflict serializability and view serializability. They aim for the same outcome — correctness — but take very different routes.
Let’s unpack what that means in practice.
Conflict Serializability
A schedule is conflict serializable if it can be transformed into a serial schedule (i.e., transactions executed one after another, no overlap) by swapping only non-conflicting operations.
Two operations conflict if they:
1. Belong to different transactions,
2. Access the same data item,
3. At least one of them is a write.
So, R1(X)W2(X), W1(X)R2(X), and W1(X)W2(X) pairs are in conflict.
Non-conflicting, operations would be R1(X)R2(X) and ones that involve different data items. For instance, R1(X)W2(Y), W1(X)R2(Y) and W1(X)W2(Y).
Because reordering non-conflicting operations preserves the outcome, conflict serializability ensures the schedule is equivalent to some serial execution guaranteeing correctness.
Looking at the examples from my previous blog post,
Given following transaction operations:
(T1) X = X - 10
(T1') Y = Y + 10
(T2) Y = Y - 5
(T2') Z = Z + 5
Valid serial orders would be:
1. T1 T1' T2 T2' (T1 -> T2)
2. T2 T2' T1 T1' (T2 -> T1)
And conflict serializable schedules would be:
T1 T2 T1' T2' (Equivalent to serial order T2 -> T1), and
T2 T1 T2' T1' (Equivalent to serial order T2 -> T1)
Notice, in both of these conflict serializable orders T1' and T2 are engaged in a RW conflict. In other words, they can't be reordered. T'1 must always follows T2 if we are leaning for serial order T2 -> T1.
We can also see that (T1, T2) and (T1', T2') can flip order without violating the serial order T2 -> T1 only because they are not in conflict with each other.
View Serializability
While conflict serializability enforces strict ordering on all RW, WR, and WW conflicts, view serializability is more relaxed. It is a superset of conflict-serializable schedules, because in certain cases a conflict can be safely ignored without affecting the correctness of the outcome.
The classic case is with write–write conflicts W1(X)W2(X). If transaction T1 writes X = 5 but then T2 overwrites it with X = 7 and the value from T1 is never observed by anyone. In this case, the system does not need to abort T1. It can simply ignore T1’s write. The final state is still X = 7, which is the same as if T1’s write never happened.
If W1(X) arrived before W2(X), then it would just be part of normal schedule, and we would keep it. But if W1(X) arrives late, after W2(X) has already committed, the database can treat it as obsolete and skip persisting it altogether.
However, there is one important caveat: if any operation did read the value written by W1(X), we can't safely ignore it anymore. This write now matters to the schedule because it influenced another transaction. Thomas' Write Rule doesn't apply to it anymore. Ignoring it would break view serializability. The system must either abort T1 or reject the conflicting read.
Conclusion
Conflict serializability is stricter than view-serializability: every conflict-serializable schedule is also view-serializable, but not vice versa. View serializability allows the system to safely accept more schedules, by recognising that some operations are obsolete and can be discarded without affecting correctness.