You are deciding whether a high-throughput OLTP service should run all of its transactions at SERIALIZABLE. What throughput and abort-rate effects do you expect, and what alternatives would you weigh for the invariants that actually need protection?

## Framing the decision Run everything at SERIALIZABLE is attractive because it removes a whole class of reasoning from application developers: no anomaly analysis, no lock-order discipline, no defensive re-reads. That is a genuine engineering saving. The question is what it costs in this workload, and whether cheaper mechanisms already cover the invariants that matter. ## Where the cost actually appears **It scales with conflict, not with volume.** Transactions whose read and write sets do not overlap are effectively unaffected: a locking implementation finds no conflicting lock; an optimistic one records dependencies but never sees a dangerous pattern. A partitioned workload — per-tenant, per-user, per-account rows — can run at SERIALIZABLE almost for free. **Hot keys are where it hurts.** A single row every transaction touches (a global counter, a sequence table, one shared inventory row) becomes the serialization point. Locking makes everyone queue behind it, so throughput on that path approaches one transaction per lock-hold time. Optimistic detection instead lets everyone run and aborts most of them; each abort wastes the work already done, so goodput can fall as offered load rises — a congestion-collapse shape rather than a plateau. **Transaction duration is the multiplier.** Conflict probability rises roughly with the window during which a transaction is exposed. A transaction holding a database transaction open across a remote call, an HTTP retry, or user think-time is orders of magnitude more likely to conflict than a 2 ms one. In most incidents, transaction length — not the isolation level — is the root cause. **Read-set width is the second multiplier.** Both mechanisms key off what a transaction read. An unindexed predicate scans and therefore locks or marks far more than it needed; add the index and both waits and aborts drop. Missing indexes often show up first as abort-rate regressions. **Second-order costs.** Retry logic on every write path; idempotency or an outbox for external side effects; tracking memory and possible granularity escalation in optimistic engines; more lock-manager memory and escalation risk in locking ones; harder capacity modelling, because throughput is no longer a simple function of CPU. ## The alternatives, roughly in order of preference **1. Declarative constraints.** If the invariant is expressible as a unique index, foreign key, check constraint or exclusion constraint, use it. The engine enforces it at every isolation level, with no dependency analysis, no retries and a clear error. Many invariants people reach for SERIALIZABLE to protect — only one active membership, no overlapping bookings — are constraint-shaped. **2. Statement-level atomicity.** Rewrite read-decide-write as one statement that reads and writes the current row (`SET stock = stock - 1 WHERE id = ? AND stock >= 1`, checking the affected row count). This eliminates the window rather than defending it, and it is the single highest-leverage fix for counter and inventory contention. **3. Explicit locking on the few hot paths.** Take a row lock on read, in a consistent order. Conflicts become short, bounded waits instead of repeated wasted work, and no retry loop is needed. Cost: deadlock risk and reduced parallelism on those rows — acceptable for a handful of paths, unmanageable as a global convention. **4. Selective SERIALIZABLE.** Apply the level to the specific transactions that enforce a multi-row invariant no constraint can express — balance checks across rows, capacity checks over a range, approval workflows. Remember the caveat: in optimistic implementations the guarantee only holds among transactions that *all* run at SERIALIZABLE and touch the same data, so selective means per-invariant, not per-statement. **5. Global SERIALIZABLE.** Correct and simple to reason about. Reasonable when the workload is well partitioned, transactions are short, and the team benefits from a uniform rule; a strong default for smaller-scale or correctness-critical systems. ## How to decide, concretely - Benchmark at *realistic contention*, not with uniform random keys — the skew is the whole story. Model the real hot keys. - Measure abort rate, attempts per successful commit, p99 latency and goodput, not just average throughput. - Inventory the invariants: which are constraint-expressible, which are single-statement-expressible, which genuinely need serial-equivalence. - Set and enforce transaction-length budgets and forbid remote calls inside transactions before touching the isolation level at all. - Instrument first: abort rate and retry counts per transaction type must be visible before you can operate the level. - Verify what the engine actually implements under that name, and remember the guarantee is per-database: replicas, caches and cross-service writes sit outside it. ## The judgement There is no universal answer, which is the point of the question. A good answer says: default to the strongest level the workload can afford, but pay for correctness with the cheapest mechanism that expresses the invariant — constraints first, single statements next, targeted locking or targeted SERIALIZABLE after that — and treat transaction length and read-set width as the levers that decide whether global SERIALIZABLE is affordable at all.