Where's the Next 100x?
Concept. Strict 2PL gives safe, correct concurrency and runs most production databases today, but it refuses many schedules that are perfectly serializable. The next 100x in throughput comes from protocols that drop Strict 2PL and admit those refused schedules: micro-locking, LSM trees, and timestamp ordering, each matched to a workload signature. The correctness target never moves; only the scheduler does.
Intuition. Correctness is a set of nested rings: Serializable on the outside, then conflict-serializable, then 2PL, with Strict 2PL the smallest ring at the core. Every ring outside Strict 2PL is safe to run, yet your database refuses it. A song landing 10M plays an hour does not need locks at all; an LSM tree appends every play and never blocks. Read the workload signature and the protocol falls out.
We built the whole transaction manager: locks, schedules, write-ahead logging, crash recovery. Strict 2PL gives you safe, correct concurrency and runs most production databases today. The next 100x comes from three protocols that drop it and admit the schedules it refuses: micro-locking, LSM trees, and timestamp ordering.
Figure 1. Scaling runs about 100x per decade. Strict 2PL, blue, is where production databases run today. The next 100x, violet, comes from protocols that drop Strict 2PL and admit the schedules it refuses; tuning 2PL itself, grey, does not scale.
The Opportunity Space
In the real world, most schedules aren't conflict-serializable under 2PL. Yet, there are countless valid schedules we can safely execute.
Figure 2. Every ring outside S2PL is safe, valid schedules that today's S2PL databases refuse to run. The Serializable − CS ring and the CS − 2PL ring are real schedules a smarter scheduler could admit; that untapped gap is the 100x opportunity.
Match the Protocol to the Workload
Look at what the system actually does. Each of these three workloads has one clear answer:
Figure 3. Each workload signature, grey, maps to one protocol, violet, and the real systems that ship it, blue. The signature is the case: a viral counter, a play stream, a shared graph.
-
A video goes viral, 10M users on one counter. That is fine-grained contention. Reach for micro-locking: lock the single field, not the whole row, so thousands of writes to one entity barely wait. Postgres, SQL Server, Oracle.
-
A song lands 10M plays in an hour. That is pure write throughput. Reach for LSM trees: append every write to an immutable file, no locks at all, with reads that settle a moment later. ClickHouse, BigQuery, Snowflake.
-
10,000 agents update one shared graph. That is global ordering. Reach for timestamp ordering: run every operation in timestamp order and abort-and-retry the conflicts instead of waiting. Spanner.
The Next Machine
Strict 2PL is the baseline of database concurrency, and the next 100x lives in the schedules it refuses. The correctness target itself is wider than 2PL enforces: what defines correct is serializability, equal to some serial order. Conflict-serializability is only the mechanical test 2PL passes, so a scheduler that admits the serializable-but-not-conflict-serializable schedules is still correct, and that gap is real headroom. Every protocol here ran on one machine. Next we break that machine into a thousand.
Figure 4. Strict 2PL, violet, is the baseline, and the next 100x lives in the safe schedules it refuses. What defines correct is serializability, green: a smarter scheduler can admit schedules that are serializable yet not even conflict-serializable. Every protocol here ran on one machine; distributed systems break that machine into a thousand, with the data, the locks, and the clock on different computers.