Serializability

Serializability guarantees that concurrent transactions produce the same result as some serial execution. Even though they run concurrently, the outcome is as if they ran one after another. Every concurrency anomaly, dirty reads, phantoms, write skew, is prevented.

The cost is performance. Achieving serializability requires pessimistic locking (2PL), optimistic validation (SSI), or deterministic execution (Calvin). Each trades throughput for correctness.

Most applications do not need full serializability. Snapshot isolation handles the majority of workloads. But for financial systems and strict inventory limits, serializability is the right choice.

Two-Phase Locking (2PL), transactions acquire shared locks for reads and exclusive locks for writes. A transaction holds all locks until it commits. Guarantees serializability but reduces concurrency because transactions block each other.

Serializable Snapshot Isolation (SSI), runs transactions under snapshot isolation but tracks read-write dependencies. If a conflict is detected at commit time, one transaction is aborted. PostgreSQL and CockroachDB use this.

Deterministic execution (Calvin), order all transactions first, then execute them in that order across all replicas. No coordination needed during execution because the order is predetermined.