Linearizability covers single objects. But real systems mutate multiple objects per transaction — transfer money between two accounts, decrement inventory while creating an order. Serializability is the guarantee that even though transactions run concurrently, the outcome is equivalent to some serial order of those transactions. No interleaving anomalies. No half-applied state visible to anyone.

Crucially, serializability says nothing about which serial order. If T1 and T2 run concurrently, the database may pick T1→T2 or T2→T1 — but never a hybrid. Strict serializability adds linearizability's real-time constraint: if T1 committed before T2 started (wall-clock), the chosen order must respect that.

The anomalies serializability prevents:

• Dirty reads: reading another transaction's uncommitted writes
• Non-repeatable reads: same query, different answers within one transaction
• Phantom reads: a range query returns new rows on re-execution
• Write skew: two transactions read overlapping data, write disjoint data, both commit, and together violate an invariant no single transaction would

Real-world example — the on-call doctor rule. Hospital policy: at least one doctor must be on-call. Alice and Bob are both on-call. Each opens a "remove myself" transaction. Each reads count(on_call) = 2, sees the invariant would still hold, and commits. Result: zero doctors on call. No individual transaction broke the rule; their combination did. This is write skew. Snapshot Isolation (Postgres' default REPEATABLE READ, MySQL's default) does not prevent this — only true serializability does.

How databases actually deliver it:

• Two-Phase Locking (2PL): acquire locks on read, hold until commit. Correct but contention-heavy.
• Serializable Snapshot Isolation (SSI): Postgres' SERIALIZABLE level — runs optimistically on snapshots, aborts transactions that would create a non-serializable cycle. Cheap when contention is low.
• Actual serial execution: Redis, VoltDB — one transaction at a time on a single thread. Insanely fast for in-memory workloads.

Rule of thumb on cost: SSI typically adds 10–30% overhead vs Snapshot Isolation under low contention, but abort rates climb sharply past ~20% conflicting writes — at which point you should partition the contended data, not crank up the isolation level. Always wrap SERIALIZABLE transactions in a retry loop with backoff; serialization failures (Postgres SQLSTATE 40001) are expected, not exceptional.

Default to your database's standard isolation. Reach for SERIALIZABLE only when you've identified an invariant that spans multiple rows or queries — the classic tell is "I need to check then act."