Three Roads to Serializability — Serial Execution, 2PL, SSI Diagram

Remove concurrency entirely: one thread runs one transaction at a time, so the result is serializable by definition
Feasible since the 2000s because the active dataset fits in RAM and OLTP transactions are short and few
Interactive round trips would waste the single thread, so whole transactions go to the database as stored procedures in a general-purpose language
Sharding gives each shard its own thread; cross-shard transactions need lockstep coordination and are orders of magnitude slower

Readers take shared locks, writers exclusive ones; locks grow until the end of the transaction and are then released at once
Writers block readers and readers block writers — the opposite of snapshot isolation's readers-never-block-writers
Predicate locks cover rows matching a search, even rows that do not exist yet; index-range locks approximate them cheaply and stop phantoms
A table-wide read (backup, analytics) locks everyone out of writes, so latency becomes unstable and deadlocks multiply

Optimistic: transactions run on a snapshot and never block; at commit the database checks for serialization conflicts and aborts if needed
It tracks stale MVCC reads and writes that affect earlier reads; a tripwire notifies readers instead of blocking writers
Only read-write transactions that acted on an outdated premise are aborted; long-running read-only transactions are safe
PostgreSQL, SQL Server Hekaton, HyPer, CockroachDB, and FoundationDB use it; the cost is bookkeeping and the abort rate under contention