View Serializability in DBMS: Blind Writes & Examples

Section 01

The Story That Explains View Serializability

📖 Real World Analogy

The Whiteboard at the End of the Day

A meeting room has a whiteboard. Three people walk in at different times, each doing some combination of reading what's on it and writing on it. At 5 pm the cleaner enters, takes a photo, and leaves. Tomorrow, the boss only cares about what was in that photo — not the order of intermediate scribbles.

So if a chaotic, interleaved sequence of read/write actions produces the same final whiteboard as some simple "one person at a time" sequence, the chaotic version is effectively view equivalent to the orderly one. The boss can't tell them apart from the photo.

That is exactly the idea of view serializability — a more forgiving correctness criterion than conflict serializability. It accepts more schedules as "safe" because it cares about what the data looks like, not the exact order of every conflict.

A schedule S is view serializable if it is view equivalent to some serial schedule of the same transactions. View equivalence is defined by three strict rules about reads and writes, covered in the next section. The class of view-serializable schedules is strictly larger than the class of conflict-serializable schedules — every CS schedule is VS, but some VS schedules are not CS.

🤝

Why We Need a Broader Class

Academic view: some clearly correct schedules contain "useless" intermediate writes that create false cycles in the precedence graph, making them look unsafe to the conflict test even though their final result matches a serial one. View serializability is the precise mathematical fix for that.
Industry view: view serializability is not used as the runtime check in real databases because testing it is NP-complete. It's a theoretical tool that tells us how much concurrency we are leaving on the table by sticking to the cheaper conflict-serializability test.

Section 02

The Three Rules of View Equivalence

Two schedules S1 and S2 (over the same transactions) are view equivalent if and only if all three conditions hold for every data item:

📋 The Three View-Equivalence Conditions

Rule 1

Initial Read. For each data item X, the transaction that performs the first read of X must be the same in S1 and S2.

Rule 2

Updated Read (Write-Read order). If transaction Ti reads a value of X written by Tj in S1, then in S2 too, Ti must read the value of X written by the same Tj.

Rule 3

Final Write. For each data item X, the transaction that performs the last write of X must be the same in S1 and S2.

💡

Memory Hook

"Same first read, same who-wrote-what-you-read, same last write." If all three match between your schedule and some serial ordering of the same transactions, it is view serializable.

Section 03

Blind Writes — The Star of This Topic

A blind write is a Write operation on a data item by a transaction that has not previously Read that same item. The transaction is "blind" to the current value — it just overwrites it.

❌ Blind Write (no prior read)

Step	Operation
1	T2: W(X) = 50
	(no R(X) anywhere before in T2)

✅ Informed Write (read first)

Step	Operation
1	T2: R(X)
2	T2: W(X) = R(X) + 10

⚠️

The Golden Connection

Without blind writes, view serializability and conflict serializability are equivalent. Every schedule that is view serializable is also conflict serializable — and vice versa. Blind writes are the only source of the gap between the two classes. Every "VS but not CS" example you will ever meet contains at least one blind write.

Section 04

What Is a Blind Write? — Examples Table

Section 03 introduced the idea. This section is a reference table you can come back to whenever an exam question or interview asks "is this write blind?". The formal definition first, then a worked-example table you can memorise.

📝

Formal Definition

A blind write Wi(X) is a write operation on data item X by transaction Ti such that Ti has not executed Ri(X) before Wi(X) within the same transaction. The "blindness" refers to Ti not knowing the current value of X — it simply overwrites whatever was there.

Worked Examples — Spot the Blind Writes

Each row below shows the operation sequence of one transaction. The third column tells you whether each Write in that sequence is blind, and why.

#	Transaction Operations	Blind?	Reason
1	W(A)	YES	The transaction writes A with no prior read of A anywhere. Pure blind write.
2	R(A), W(A)	NO	R(A) precedes W(A) in the same transaction → informed write.
3	R(B), W(A)	YES	Reading B does not "inform" the write on A. Blindness is checked per item.
4	R(A), R(B), W(A), W(B)	NO · NO	Each item read before being written. Neither write is blind.
5	W(A), R(A), W(A)	YES · NO	The first W(A) is blind (no prior R). The second W(A) follows R(A), so it is informed. Each Write is evaluated independently.
6	R(A), W(B), W(A)	YES · NO	W(B) is blind (no R(B) anywhere). W(A) is informed because R(A) precedes it.
7	W(A), W(A)	YES · YES	Both writes are blind — an earlier write by the same transaction does not count as a "read", because writing does not inform you of the prior value.
8	R(A) in T1, then W(A) in T2	YES	Different transactions! Blindness is checked within one transaction. T2 did not read A → W(A) by T2 is blind.

⚠️

The Two Common Traps

Trap 1: Blindness is per item — reading B never makes W(A) informed (row 3). Trap 2: Blindness is per transaction — another transaction's read does not inform your write (row 8). When in doubt, ask: did THIS transaction read THIS item before this Write?

Industry Examples — Where Blind Writes Show Up in Real SQL

Most application code does not produce blind writes, but a few common SQL patterns do. Recognising them helps you anticipate where the CS-vs-VS gap can actually matter in production.

SQL Statement	Blind?	Why
INSERT INTO orders VALUES (…)	YES	Inserts create new rows — no prior read possible. Every INSERT is a blind write.
UPDATE accounts SET balance = 0 WHERE id = 7	YES	The new value (0) does not depend on the old. No SELECT precedes it → blind.
UPDATE accounts SET balance = balance + 100 WHERE id = 7	NO	The right-hand side reads `balance` first to compute the new value. Implicit read → not blind.
SELECT … FOR UPDATE then UPDATE	NO	The explicit SELECT supplies the prior read. This is the safe, common pattern.
DELETE FROM cache WHERE key = 'x'	YES	DELETE writes (removes) without needing to read the value first → counts as blind.

💡

Why This Matters in Practice

In real systems, blind-write-heavy workloads — bulk INSERTs, cache invalidations, audit log appends — are exactly the cases where the gap between view and conflict serializability could theoretically buy you more concurrency. Engines do not exploit it (the NP-complete test is too expensive), but knowing the pattern helps you understand why these workloads sometimes scale better under weaker isolation levels.

Section 05

The Hierarchy — Where Does VS Sit?

Schedule Class Hierarchy (Venn View)

Each ring strictly contains the smaller ones. The ring difference VS − CS is non-empty only because of blind writes.

Class	Test Cost	What It Catches	Used In Practice?
Serial	O(1) — obvious	Trivially safe	Too slow to be useful
Conflict Serializable	Polynomial (precedence graph)	Most useful safe schedules	Yes — 2PL, SSI
View Serializable	NP-complete	A few extra schedules with blind writes	No — only theoretical
All Schedules	—	Includes anomalous ones	Not safe

Section 06

The Algorithm — How to Check View Serializability

Try Conflict Serializability First

Draw the precedence graph. If it is acyclic, the schedule is conflict serializable — and therefore automatically view serializable. Done.

If the Graph Has a Cycle, Look for Blind Writes

If there is no blind write anywhere in the schedule, the verdict is final: NOT view serializable. Stop.

If Blind Writes Exist — Try Each Serial Order

For each of the k! possible serial orders of the transactions, check whether it is view equivalent to S using the three rules from Section 02. If at least one matches, the schedule is view serializable.

No Match Among All Serial Orders → NOT View Serializable

Only after ruling out every serial order do you conclude non-view-serializable. This step is what makes the test NP-complete in general.

Section 07

Numerical 1 — VS But NOT CS (The Classic Blind-Write Example)

Consider this widely cited textbook schedule with three transactions and one data item A:

Schedule S1

S1: R1(A), W2(A), W1(A), W3(A)

Time	Transaction 1	Transaction 2	Transaction 3
t1	R(A)
t2		W(A)
t3	W(A)
t4			W(A)

Step 1 — Conflict Serializability Check

🧮 Conflict Pairs on Item A

Pair 1

R1(A) @t1 before W2(A) @t2 — RW → edge T1 → T2

Pair 2

W2(A) @t2 before W1(A) @t3 — WW → edge T2 → T1

Pair 3

W2(A) @t2 before W3(A) @t4 — WW → edge T2 → T3

Pair 4

W1(A) @t3 before W3(A) @t4 — WW → edge T1 → T3

Precedence Graph — Cycle Found

Red arrows: cycle T1 ↔ T2 → conflict-serializability fails. But before giving up, we must check for blind writes.

❌

NOT Conflict Serializable

The cycle T1 ↔ T2 rules out conflict serializability. We cannot stop here — the schedule may still be view serializable. Next step: look for blind writes.

Step 2 — Blind Write Check

🔎 Reading the Schedule Transaction by Transaction

R(A) then W(A). Reads before writing → not blind.

W(A) only. No prior R(A) → BLIND WRITE. 🎯

Blind writes exist → the schedule might still be view serializable. Now we test each of the 3! = 6 serial orders against the three view-equivalence rules.

Step 3 — Find a View-Equivalent Serial Schedule

In S1: the first read of A is by T1, and the last write of A is by T3. No transaction reads a value written by another (there is only one read overall, and it happens before any write). So any serial schedule satisfying these is view equivalent to S1.

🧮 Try Serial Order: T1 → T2 → T3

Order

R1(A), W1(A), W2(A), W3(A)

Rule 1

First read of A in S1 = T1. First read here = T1. ✓ Match

Rule 2

No write-read pairs across transactions in either schedule. ✓ Vacuously true

Rule 3

Last write of A in S1 = T3. Last write here = T3. ✓ Match

✅

Verdict — VIEW Serializable (but NOT Conflict Serializable)

S1 is view equivalent to the serial schedule T1 → T2 → T3. The "useless" intermediate write W2(A) is overwritten by W3(A) and never read — its order doesn't actually matter for any reader. This is the gap between VS and CS in action.

Section 08

Numerical 2 — NOT View Serializable (No Blind Writes)

Consider this schedule:

Schedule S2

S2: R1(A), R2(A), W1(A), W2(A)

Time	Transaction 1	Transaction 2
t1	R(A)
t2		R(A)
t3	W(A)
t4		W(A)

Step 1 — Conflict Serializability

🧮 Conflict Pairs on Item A

Pair 1

R1(A) before W2(A) — RW → edge T1 → T2

Pair 2

R2(A) before W1(A) — RW → edge T2 → T1

Pair 3

W1(A) before W2(A) — WW → edge T1 → T2 (already exists)

Precedence Graph — Cycle

Cycle T1 ↔ T2 → not conflict serializable. Check blind writes next.

Step 2 — Blind Write Check

🔎 Per-Transaction Audit

R(A) then W(A) — reads first, not blind.

❌

Verdict — NOT View Serializable

Cycle in precedence graph and no blind writes anywhere. By the rule from Section 03, the schedule cannot be view serializable. Stop here — no need to try the six serial orders. This is also the classic lost update anomaly.

Section 09

Numerical 3 — Three Transactions, Blind Write Saves the Day

Consider:

Schedule S3

S3: R1(A), W2(A), R3(A), W1(A)

Time	Transaction 1	Transaction 2	Transaction 3
t1	R(A)
t2		W(A)
t3			R(A)
t4	W(A)

Step 1 — Conflict Serializability

🧮 Conflict Pairs on Item A

Pair 1

R1(A) @t1 before W2(A) @t2 — RW → edge T1 → T2

Pair 2

W2(A) @t2 before R3(A) @t3 — WR → edge T2 → T3

Pair 3

W2(A) @t2 before W1(A) @t4 — WW → edge T2 → T1

Pair 4

R3(A) @t3 before W1(A) @t4 — RW → edge T3 → T1

Precedence Graph — Cycle T1 ↔ T2

Cycle T1 ↔ T2 in red. Conflict-serializability fails — investigate blind writes.

Step 2 — Blind Write Check

🔎 Per-Transaction Audit

R(A) then W(A) — not blind.

W(A) only — no prior R(A) → BLIND WRITE. 🎯

R(A) only — not a write at all. Not blind.

Step 3 — Find a View-Equivalent Serial Schedule

Observations about S3 we must preserve:

📋 What S3 "Looks Like" in View Terms

Initial read

R1(A) is the first read of A → T1 reads the initial value.

Updated read

R3(A) reads the value written by W2(A) → T3 reads from T2.

Final write

W1(A) at t4 is the last write of A → T1 performs the final write.

Now look for a serial order that preserves all three. Try T2 → T3 → T1:

Serial Schedule T2 → T3 → T1

W2(A), R3(A), R1(A), W1(A)

🧮 Verifying the Three Rules

Rule 1

First read of A in this serial = R3(A) by T3. But in S3, the first read is by T1! ✗ Mismatch

Rule 1 fails. Try T1 → T2 → T3:

Serial Schedule T1 → T2 → T3

R1(A), W1(A), W2(A), R3(A)

🧮 Verifying the Three Rules

Rule 1

First read of A = T1 in both. ✓ Match

Rule 2

In S3: T3 reads from T2. In serial: T3 reads from T2 (W2(A) is the only write before R3(A)). ✓ Match

Rule 3

Last write of A in S3 = T1 (at t4). Last write in serial = T2. ✗ Mismatch

Rule 3 fails. The last write in S3 is T1, but no serial order ending in T1 can let T3 read T2's value and have T1's read come first — you can verify by trying T2 → T1 → T3 and the remaining permutations. Every one fails at least one rule.

❌

Verdict — NOT View Serializable

Despite the presence of a blind write in T2, no serial order of {T1, T2, T3} is view equivalent to S3. The blind write made it possible for VS to hold — but possibility is not certainty. This is the educational point: blind writes are necessary but not sufficient for VS-but-not-CS.

Section 10

Side-by-Side Recap — The Three Verdicts

✅

Numerical 1 — VS only

Cycle + Blind Writes + Match

R1(A), W2(A), W1(A), W3(A). Conflict graph has a cycle; T2 and T3 are blind writers; serial order T1 → T2 → T3 is view equivalent. VS yes, CS no.

❌

Numerical 2 — Neither

Cycle + No Blind Writes

R1(A), R2(A), W1(A), W2(A). Cycle in the precedence graph; both transactions read before writing. The "lost update" classic. VS no, CS no.

❌

Numerical 3 — Blind Write, Still Fails

Cycle + Blind Write but No Match

R1(A), W2(A), R3(A), W1(A). Cycle; T2 is a blind writer; but no serial order preserves first read = T1, T3 reads from T2, last write = T1 simultaneously. VS no, CS no.

Section 11

Academic View vs Industry View

🎓 Academic Lens

Aspect	Detail
Definition	View equivalence to some serial order
Rules	Initial read, updated read, final write
Class size	Strictly larger than CS
Test cost	NP-complete in general
Source of extra class	Blind writes

🏭 Industry Lens

Aspect	Detail
Used at runtime?	No — too expensive to verify
What engines use	Conflict serializability (2PL, SSI)
What is lost	A few extra valid schedules with blind writes
Practical impact	Negligible — blind writes are rare in real workloads
Use today	Teaching, theory of concurrency

📊

The Engineering Takeaway

Real databases never compute view serializability. The NP-completeness alone kills it; on top of that, blind writes are uncommon in well-written application code (most writes either follow a read of the same row or are inserts). The polynomial conflict-graph test catches essentially everything that matters, and locks/SSI prevent cycles before they occur. View serializability survives as a teaching device that shows where the theoretical ceiling sits.

Section 12

Rapid-Fire Concept Check

Question	Answer
The three rules of view equivalence	Initial read, updated read, final write
A write without a prior read in that transaction is called	Blind write
If a schedule is conflict serializable, is it view serializable?	Yes (always)
If a schedule is view serializable, is it conflict serializable?	Not necessarily
Without blind writes, VS = ?	CS
The complexity of testing view serializability	NP-complete
Cycle in precedence graph and no blind write → verdict?	Not view serializable
Cycle in precedence graph and blind write → verdict?	Might or might not be VS — test serial orders
Number of serial orders to try for k transactions	k!
What real-world DBMS engines use instead	Conflict serializability (2PL, SSI)

Section 13

Golden Rules

📖 View Serializability — Non-Negotiable Rules

Two schedules are view equivalent if and only if they agree on initial reads, updated reads, and final writes for every data item. Missing any one disqualifies the pair.

A schedule is view serializable if it is view equivalent to at least one serial schedule of its transactions. You only need to find one match.

Conflict Serializable ⊂ View Serializable. Always start with the precedence graph — if it is acyclic, you are done (VS is automatic). Only fall back to the harder VS test when CS fails.

No blind write ⇒ VS ≡ CS. If the precedence graph has a cycle and there is no blind write anywhere, declare the schedule NOT view serializable immediately. Stop. Do not try serial orders.

Blind writes are necessary but not sufficient for "VS but not CS". Their presence opens the possibility — you still have to verify a view-equivalent serial order exists.

Testing view serializability is NP-complete. That is why no real DBMS uses it as a runtime correctness criterion — conflict serializability does the heavy lifting in practice.

In exams, the "VS but not CS" answer always involves a blind write that becomes irrelevant because a later write overwrites it before anyone reads it. Spot that pattern and you have spotted the trick.