Eventually-Consistent Databases — Is It Over?

Introduction: ACID and BASE — Two Paths for Database Evolution

In the early 2010s, the professional community of developers and distributed systems architects was buzzing with the idea that the world of databases was entering a new era. Against the backdrop of major internet services' successes, the term BASE began to be used as a counterpoint to the classic ACID. The hype around NoSQL, the CAP theorem, and scalable systems spawned slogans like "SQL is dead," "ACID is for banks, we build the web," and "eventual consistency is fine."

However, a decade and a half later, major cloud and enterprise platforms still speak the language of transactions, isolated operations, and strict consistency.

What happened? Was the "ACID vs. BASE battle" a real technological fault line, or did it merely reflect the limitations of its time?

In this article, we'll examine how ACID and BASE emerged, why BASE quickly gained popularity, and what the claim "ACID won" actually means in the 2020s.

ACID Transactions as an Engineering Standard

The properties of ACID (Atomicity, Consistency, Isolation, Durability) were formalized in the 1970s-1980s alongside the development of transactional databases for banks and other large information systems.

The canonical theoretical work on ACID is the book Transaction Processing: Concepts and Techniques (1993) by Jim Gray and Andreas Reuter. In it, the ACID acronym stands for:

• Atomicity: a transaction either executes completely or not at all. This property is ensured by the rollback mechanism.
• Consistency: a transaction transitions the system from one consistent state to another, provided that the application logic correctly describes the invariants.
• Isolation: concurrent transactions do not interfere with each other; the effect is at least equivalent to some serial order. This property is also known as serializability.
• Durability: committed changes are not lost in case of failures. This is ensured by the transaction log and the Write-Ahead Logging (WAL) protocol.

ACID transactions addressed the key need of their era: predictable and correct data handling under concurrent access and failures. They offered formal mechanisms for consistency and recovery, allowing the system to maintain logical integrity even when things went wrong.

The main value of ACID was that all the complexity of managing concurrent operations and errors was moved from application code into the database engine. Developers didn't need to manually "glue together" states, track partially completed operations, or think about recovery after failures — the database took on this responsibility and guaranteed correct results.

It was precisely on such systems that banks, stock exchanges, and corporate settlement complexes ran for decades — heavy, monolithic digital machines for which data unpredictability was an unaffordable luxury. ACID compliance became the hallmark of a "normal" database, and systems without transactional guarantees were considered niche or auxiliary.

However, by the late 1990s, this world began to "crack at the seams." The internet brought global distribution, unreliable networks, and demands for constant availability — conditions under which the classic assumptions of centralized transactional databases increasingly stopped working. In these conditions, a demand arose for new architectures and a rethinking of familiar data handling guarantees.

The CAP Theorem: Formalizing New Challenges

In 2000, at the PODC symposium, Eric Brewer presented a talk titled "Towards Robust Distributed Systems." He formulated the CAP theorem:

"In a distributed system with network partitions, it is impossible to simultaneously guarantee both strict consistency and availability."

At that point, CAP was more of an engineering intuition than a rigorous result, and it required formal justification. This challenge was taken up by the academic community.

Soon, Seth Gilbert and Nancy Lynch (MIT) established the formal rigor of the CAP theorem in their paper "Brewer's Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services" (2002), in which they:

• Introduced a formal model of a distributed system
• Strictly defined Consistency (strict consistency), Availability, and Partition tolerance
• Proved that under partition conditions, it is indeed impossible to simultaneously ensure both properties

The CAP theorem elevated the discussion about distributed systems to a new level, legitimizing engineering compromises that already existed in practice. It provided a language for asserting that abandoning strict consistency is not an engineering weakness but a consequence of fundamental limitations of distributed systems.

However, in the public sphere, CAP was quickly reduced to a convenient slogan: "In distributed systems, you need to choose between consistency and availability."

This is where oversimplification began. CAP states that in the presence of network partitions, a system must sacrifice either consistency or availability. But in popular retelling, this nuance disappeared. A theorem describing failure modes came to be perceived as a universal architectural verdict.

This interpretation proved extremely convenient. It fit well into presentations and articles and was supported by the public successes of Amazon, Google, and Facebook — scalable services demonstrating high availability, global distribution, and the ability to continue operating even when individual nodes failed. Against this backdrop, a persistent feeling formed that strict consistency inevitably had to be sacrificed at global scale.

Later, Eric Brewer himself repeatedly clarified and criticized this reading of CAP, emphasizing that consistency and availability are not a binary choice and depend on the specific operating conditions of the system.

Dynamo: The Practical Reason to Abandon Transactions

The CAP theorem provided the language for describing compromises that were being actively implemented in distributed systems. In 2007, Amazon published the paper "Dynamo: Amazon's Highly Available Key-value Store," describing an internal data storage system prioritizing high availability and scalability.

The rejection of transactions and strict consistency in Dynamo was a deliberate engineering compromise, not an ideological opposition to ACID. The system was developed for specific Amazon services — primarily the shopping cart, user sessions, settings, and auxiliary metadata — where brief inconsistency was considered an acceptable price for fault tolerance and continuous operation.

The Dynamo experience showed that:

• Eventual consistency can be acceptable
• Divergence between replicas is a conscious compromise
• Business is sometimes willing to pay with logical complexity for SLA guarantees

It was after Dynamo that the idea of "relaxed guarantees" became widely perceived as normal engineering practice.

NoSQL and the Birth of BASE

Literally the year after Dynamo was presented, in 2008, Dan Pritchett (eBay) introduced the term BASE ("BASE: An Acid Alternative," ACM Queue, 2008). It drew on the popular interpretation of the CAP theorem and stands for:

• Basically Available — the system strives to be available for operations at all times
• Soft State — state may temporarily be "soft," meaning different replicas diverge
• Eventual Consistency — if updates stop, all replicas will eventually converge to the same value

BASE was conceived as the antithesis of ACID — a simple and memorable language for describing systems like Dynamo. Its rhetoric was deliberately sharp: availability and scalability were declared fundamental properties, while strict consistency was consciously pushed to the background. As a result, BASE quickly stopped being perceived as a specific engineering compromise and began to be interpreted as an alternative philosophy for database design.

This approach resonated with systems facing new operating conditions where:

• Data was growing by orders of magnitude
• Latency requirements were in the tens of milliseconds
• Users were distributed globally
• Vertical scaling had stopped working

Against this backdrop, NoSQL solutions with a BASE philosophy felt like a "breath of fresh air," offering:

• Simple key-value interfaces
• Linear scaling by number of nodes
• The ability to write data even during partial failures

In essence, the industry was making a utilitarian choice: better temporarily "dirty" but always available data than strict transactions with high latency and risk of outages. In the context of rapidly growing internet services, availability and scalability were perceived as the key business values.

Amazon Dynamo and Its Heirs

Although the original Dynamo was an internal Amazon system, its architecture became a template for an entire family of databases.

Cassandra: Industrial Implementation of the BASE Approach

Apache Cassandra (originally Facebook, then Apache) is one of the brightest examples of BASE's success. Its features include:

• An eventual consistency model with configurable consistency levels
• Architectural orientation toward availability and partition tolerance
• The ability to scale linearly

Cassandra could survive node failures without downtime and serve enormous data volumes with predictable latency. In the early 2010s, Cassandra was actively used at Facebook (Inbox Search), Netflix, and eBay.

Riak: A Distributed System Ahead of Its Market

Riak was a key-value database inspired by Dynamo, actively promoted as the embodiment of BASE, combining:

• Eventual consistency
• Quorum-based operations
• High availability
• Erlang and fault tolerance

In the early 2010s, Riak quickly captured engineering attention as one of the most consistently implemented distributed key-value databases. It was used at Comcast, Best Buy, AT&T, Rovio, and Wikia.

However, problems emerged:

• Difficulty reasoning about data
• Version conflicts
• High cognitive load on developers

The commercial company Basho went bankrupt in 2017. Riak is often cited as a system that was conceptually right for the BASE era but proved too complex for mainstream business.

MongoDB: BASE in a Soft, Convenient Form

MongoDB of the early 2010s wasn't pure BASE in the Dynamo spirit, but:

• It had no transactions
• Eventual consistency was implemented during replication
• Priority was given to simplicity and development speed

MongoDB quickly became a popular choice for web applications and startups. Notable early adopters included The New York Times (content and metadata), MTV Networks (user data), and SourceForge (project metadata).

Problems with Misinterpreting BASE

In practice, BASE was often translated into an extremely simplified doctrine: "Consistency doesn't matter, users will survive."

But eventual consistency is not just temporary "dirt" in data. It involves:

• Complex conflict scenarios during writes
• Non-obvious races during read/write operations
• Behavior dependent on rare network and timing anomalies

In many projects, these "side effects" were underestimated. The result: elusive bugs that manifested only under load or during failures. For example, in weakly consistent stores of trading systems, the same item could be sold to two buyers simultaneously, or items could disappear from shopping carts — classic examples of replica desynchronization.

The conclusion was clear: BASE is not a "new standard" but a conscious compromise for specific classes of problems. BASE works wonderfully for social networks, telemetry, streaming, and analytical logging. But it is extremely dangerous when dealing with money, reservations, inventory tracking, and critical user data.

The Technological Turning Point: Scalable ACID

By the early 2010s, systems began appearing that showed strict ACID guarantees could coexist with horizontal scaling.

Google Spanner and External Consistency

In 2012, Google published "Spanner: Google's Globally-Distributed Database" (OSDI 2012). It demonstrated that it was possible to build a globally distributed, multi-version database with external (strict) transactional consistency and automatic sharding.

Technically, this was achieved through a combination of:

• Multi-version concurrency control (MVCC)
• Distributed consensus (Paxos)
• Global synchronized time (TrueTime API)

Google Spanner was not a rejection of BASE but the logical result of accumulated experience. It showed that with sufficient infrastructure, strict consistency can be cheaper than the consequences of logical errors.

The NewSQL Era: Rethinking Distributed Databases

As systems combining horizontal scaling with strict transactional guarantees appeared, the term NoSQL became inadequate. New solutions no longer abandoned transactions and SQL interfaces but instead brought them back into a distributed context. The term NewSQL was introduced to mark this shift.

Systems implementing this approach followed: CockroachDB, TiDB, YugabyteDB, YDB, as well as distributed extensions for PostgreSQL. They offered:

• Horizontal scaling
• Transactions with strong or near-strong consistency
• SQL compatibility with existing tools

Does this mean the CAP theorem was wrong? No. NewSQL systems don't disprove CAP — they demonstrate that with sufficient infrastructure and precise failure control, the area where hard choices between consistency and availability are necessary can be substantially narrowed.

What Happened to BASE Projects?

Riak has effectively left active development. Cassandra and MongoDB continue to be widely used, but both have evolved significantly:

MongoDB made a clear transition from BASE to ACID: first single-document atomicity, then multi-document transactions (introduced in 2018), and finally strengthened consistency guarantees.

Cassandra's developers were slightly behind but are now actively developing lightweight transactions (LWT, Paxos), expanding transactional capabilities, and developing decentralized transactions based on the ACCORD protocol.

Cloud providers (AWS, GCP, Azure) have added transactions to previously non-transactional services, choice of consistency levels (strong / eventual / bounded staleness), and automatic replication and sharding management.

What Does "ACID Won" Mean?

After a decade of experiments with NoSQL, BASE, and relaxed consistency models, it became clear that the conversation about ACID's "victory" doesn't reduce to a simple opposition. The "victory" should be understood as a shift in engineering priorities driven by accumulated practical experience operating distributed systems.

In modern architectures, transactional guarantees are increasingly viewed as the engineering default. When designing new storage, consistency and isolation levels are discussed first, and only then — methods of scaling and load distribution.

BASE has lost its status as a universal philosophy and has become a specific engineering technique. Relaxed consistency models are still actively used, but selectively — in caches, telemetry, logging, and auxiliary subsystems.

Conclusions

1. BASE was not a mistake, but it didn't become a universal alternative to ACID. It played the role of a necessary stage, allowing the industry to master horizontal scaling and gain practical experience with distributed systems under weak consistency.
2. The language of BASE became outdated faster than the engineering ideas behind it. Rough formulations like "eventual consistency" and "soft state" proved too imprecise for describing the real guarantees and anomalies encountered in modern systems.
3. ACID evolved rather than "returned." New-generation distributed databases showed that strict transactional guarantees can coexist with scalability and global distribution given sufficient infrastructure and engineering maturity.
4. The modern choice is not between ACID and BASE but between specific guarantees and their cost. Strict consistency has become the engineering default for critical data, while relaxed models are applied selectively and consciously.

ACID "won" not because BASE was bad, but because over the past 15-20 years the industry learned to scale strict guarantees while preserving their key advantage — formal and verifiable data correctness. Without BASE, this would not have happened.

Timeline: How Attention to ACID and BASE Changed

Commentary by Konstantin Osipov

I agree that strict consistency is winning the market. But beyond the complexity for users, I see other reasons:

• Infrastructure has improved significantly — outages between data centers are rarer, there are more redundant links, HDDs have been replaced by SSDs
• It's become clear that in practice, you don't need to design a single database as strictly CP or AP — you can combine approaches for different database functions

The CAP theorem is binary, but in practice the choice is much broader. For example, the data dictionary and cluster topology can be managed by strictly consistent, quorum algorithms, while data can be eventually consistent. The quorum composition can be changed dynamically in response to failures. Or you can combine a quorum algorithm when quorum exists with a bully approach — where upon quorum loss, the primary data center remains leader and preserves write availability.

Daniel Abadi, a professor who has devoted much attention to distributed systems, formulated the hypothesis that strict consistency doesn't affect throughput but only affects latency. And cross-continental latency, for example US-Australia, has been steadily approaching its theoretical minimum of 120-150 milliseconds — sufficient for most users.

Interestingly, DynamoDB, one of the first eventually consistent systems, has changed radically over the past 10 years: LSM trees, which underpin most eventually consistent databases, were replaced by B-trees from classic transactional databases. Request replication by the coordinator, also used in eventually consistent databases, was replaced by log replication (remember walsender in PostgreSQL?). First single-partition, then multi-partition transactions appeared.

The irony of this story for developers is that despite the dramatic pivot at the individual database level, designing strictly consistent applications hasn't become easier. This is because the number of databases in an average project has grown significantly — Kafka, Redis, PostgreSQL, Cassandra — today's standard gentleman's set. And consistency of data distributed across multiple databases is the developer's own responsibility. So the result isn't guaranteed simply by choosing a database. You need to think through failure scenarios at the application level, write integration tests, and design application code differently.