SaarDB Dev Log: How Transactions Solve Atomicity and Isolation in Databases

Developer blog series SaarDB reaches Part 4, tackling the core database challenges of atomicity and isolation in its custom-built storage engine. Without transactions, a crash between two related writes — such as a bank transfer — can leave data in an inconsistent state, with funds effectively disappearing. The post illustrates three concurrency anomalies: dirty reads, lost updates, and write skew, each showing how concurrent transactions can corrupt data in distinct ways. SQL databases address these issues through four isolation levels — Read Uncommitted, Read Committed, Repeatable Read, and Serializable — each preventing more anomalies at the cost of reduced concurrency. The series will focus on implementing Serializable isolation, the strictest level, which prevents all three anomalies.