Loading field map
Every database transaction—a sequence of reads and writes that must appear atomic, consistent, isolated, and durable—faces a fundamental tension: how to guarantee these properties when multiple transactions execute concurrently, when the system can fail at any moment, and when data is spread across many machines. The history of transaction processing is the story of different frameworks that have answered this tension in distinct ways, each making different trade-offs among correctness, performance, scalability, and availability.
The first systematic framework for transaction correctness was the ACID set of properties (Atomicity, Consistency, Isolation, Durability), formalized in the 1970s. ACID provided a clear correctness standard: a transaction either completes entirely or not at all, it preserves database consistency, its effects are isolated from other concurrent transactions, and its results survive failures. ACID itself is a specification, not an implementation; it defines what a transaction should guarantee without saying how to achieve it.
The earliest concrete mechanism for enforcing ACID isolation was Two-Phase Locking (2PL) , also from the 1970s. Under 2PL, a transaction acquires locks on data items as it reads or writes them, and releases all locks only after it has finished (the two phases: growing and shrinking). 2PL directly implements the isolation property of ACID by preventing conflicting operations from interleaving. For decades, 2PL was the default concurrency-control method in commercial databases, and it remains in use today, often combined with other techniques.
The 1980s saw a burst of alternative concurrency-control frameworks, each offering a different answer to the question of how to handle concurrent access without sacrificing performance.
Multiversion Concurrency Control (MVCC) keeps multiple versions of each data item so that a reader can see a consistent snapshot without blocking writers, and writers do not block readers. MVCC avoids many of the read-write conflicts that plague 2PL, making it especially attractive for read-heavy workloads. Today, MVCC is the dominant concurrency-control framework in relational databases (e.g., PostgreSQL, Oracle) and in many NewSQL systems. It often coexists with 2PL: MVCC handles reads, while 2PL or other mechanisms manage write-write conflicts.
Optimistic Concurrency Control (OCC) takes a different approach: it lets transactions execute freely without locking, then validates at commit time whether any conflicts occurred. If a conflict is detected, the transaction is aborted and retried. OCC works well under low contention but wastes work when conflicts are frequent. It never replaced 2PL or MVCC in mainstream databases, but it found a niche in memory-optimized systems and in environments where conflicts are rare.
Timestamp Ordering (TO) assigns each transaction a unique timestamp and processes operations in timestamp order, aborting any transaction that attempts to read or write out of order. TO provides a clean theoretical model for serializability and is simple to reason about, but its practical adoption has been limited because it requires tight clock synchronization and can cause many aborts under high contention. It persists as a reference baseline for concurrency-control research and as a component in some distributed systems.
These three frameworks—MVCC, OCC, and TO—did not replace 2PL so much as they expanded the design space. MVCC became the workhorse for most systems; OCC remained a specialized alternative; TO served as a conceptual anchor. Their coexistence illustrates that no single concurrency-control strategy dominates all scenarios.
When data is distributed across multiple machines, the atomicity and isolation guarantees of ACID become harder to enforce. Two-Phase Commit (2PC) , introduced in the 1980s, extends atomicity to distributed transactions: a coordinator asks all participants to prepare (phase one), and if all agree, instructs them to commit (phase two). 2PC is blocking: if the coordinator fails after sending the prepare messages, participants may remain uncertain and hold locks indefinitely. This weakness motivated the development of Consensus Protocols in the 1990s, such as Paxos and later Raft. Consensus protocols allow a group of nodes to agree on a value even if some nodes fail, and they are non-blocking: as long as a majority of nodes are alive, progress can continue. Consensus protocols have become the infrastructure layer for many later frameworks, including NewSQL and Cloud-Native Transaction Managers. They did not entirely replace 2PC—2PC is still used in some settings where blocking is acceptable—but consensus is now the preferred foundation for high-availability distributed transactions.
In the early 2000s, the rise of large-scale web applications exposed the limitations of ACID in environments that demanded high availability and partition tolerance. BASE Semantics (Basically Available, Soft state, Eventually consistent) emerged as a philosophical counter-framework. BASE prioritizes availability over immediate consistency: a system remains available even during partitions, accepts that data may be temporarily inconsistent, and guarantees that it will become consistent over time. BASE is not a formal protocol like 2PL or MVCC; it is a design principle that influenced the NoSQL movement (e.g., Cassandra, DynamoDB). BASE and ACID now coexist in polyglot persistence architectures: applications choose ACID for critical financial data and BASE for high-throughput, less critical data. The tension between them remains a central debate in the field.
The 2010s and beyond have seen a wave of frameworks that attempt to combine the guarantees of ACID with the scalability of distributed systems.
NewSQL is a family of systems (e.g., Google Spanner, CockroachDB) that provide full ACID transactions across distributed data, often using consensus protocols for replication and MVCC for concurrency control. NewSQL directly challenges the BASE philosophy by showing that strong consistency can be achieved at global scale, albeit with higher latency. It builds on the infrastructure of consensus and MVCC while rejecting the availability-first trade-off of BASE.
Deterministic Databases (e.g., Calvin) take a radical approach: they pre-order all transactions before execution, eliminating the need for runtime conflict detection. By knowing the order in advance, the system can execute transactions without locking or validation, achieving high throughput under low contention. Deterministic databases share OCC's assumption that conflicts are rare, but they avoid the wasted work of aborts by ensuring that the pre-determined order is conflict-free. This framework has not seen widespread adoption but remains an active research direction.
Hardware-Assisted Transactional Memory (HTM) leverages processor-level support for optimistic concurrency: the CPU tracks read and write sets and aborts transactions on conflicts, falling back to a software path if needed. HTM is a database transaction framework because it provides a hardware-accelerated implementation of the isolation property. However, its scope narrowed over time: hardware limitations (cache capacity, conflict detection granularity) prevented it from becoming a general-purpose replacement for software concurrency control. HTM now serves as a specialized accelerator in some in-memory databases.
Cloud-Native Transaction Managers (e.g., Amazon Aurora, Google Spanner) represent the current frontier. They combine consensus protocols for fault tolerance, MVCC for concurrency control, and asynchronous replication for elasticity. These managers are designed to run on commodity cloud infrastructure, scaling out and in automatically. They absorb earlier frameworks: 2PC may be used for cross-partition transactions, consensus for replication, and MVCC for isolation. Cloud-Native Transaction Managers are becoming the default choice for new applications that need both ACID guarantees and cloud elasticity.
Today, the leading frameworks in transaction processing are MVCC (dominant in almost all relational and NewSQL systems), Consensus Protocols (the foundation for distributed coordination), and Cloud-Native Transaction Managers (the emerging standard for cloud deployments). They agree on the importance of serializability or strong consistency for many workloads, and they share a reliance on MVCC for read performance. They disagree on the acceptable latency cost of strong consistency: NewSQL systems accept higher latency for global serializability, while Cloud-Native Transaction Managers often relax consistency to single-region or single-partition scopes for lower latency. BASE semantics remains influential for systems that prioritize availability above all else, and the field continues to explore hybrid approaches that blend ACID and BASE guarantees. The tension between correctness and performance, once framed as a binary choice, is now managed through a rich toolkit of frameworks that can be combined and tuned for specific application needs.