From ACID to BASE

In Dining Dollars, a purchase subtracts the amount from the student’s balance and adds an entry to the ledger. Both changes happen in one transaction, so they happen together or not at all. The balance can never go below zero. Two purchases at the same time cannot both spend the same money. Once a purchase is confirmed, a crash cannot lose it. These are the ACID properties, and the database provides them.

With replication, we also have to decide how long an operation waits for the replicas. If a read has to return the latest write, the replicas have to coordinate, and a partition can prevent that.

When an application can show old data for a while, we can keep serving requests during a failure and let the replicas catch up later. This approach is called BASE. People often compare it with ACID.

What BASE means

BASE stands for three properties:

  • Basically available: the system keeps serving requests during a failure. Some responses may return old data, and some features may be unavailable. For example, during the partition in our example of one primary and one replica, Shopend keeps serving catalog reads but refuses to place orders.
  • Soft state: stored data can change without a new request, because the replicas are still catching up. When the replica applies the merchant’s price change, the price it stores changes, even though no one sent the replica a request.
  • Eventually consistent: the replicas can disagree for a while, but they all end up with the same data.

BASE compared with ACID

ACID describes one transaction. It says what the database guarantees when that transaction changes the data. BASE describes the whole system. It says how the system keeps serving requests while the replicas have different data.

The word consistency means something different in each. In ACID, it means the constraints on the data hold. In BASE, it means the replicas end up with the same data.

A system can use both. For example, in Shopend, placing an order is one ACID transaction on the primary: it reduces the stock, records the order, and updates the cart together. Catalog reads go to the replicas, which apply the primary’s changes after a delay. While browsing, a shopper may see an old price or stock quantity until the replicas catch up. The order has every ACID guarantee, and the catalog reads are eventually consistent.

ACID, BASE, and NoSQL databases

The name BASE was chosen as the opposite of ACID. It comes from a 1997 paper by Armando Fox, Steven Gribble, Yatin Chawathe, Eric Brewer, and Paul Gauthier at UC Berkeley. They were building web services that ran on clusters of many servers. They argued that many web services do not need ACID, and that giving it up makes it simpler and cheaper to keep a cluster serving requests when some of its machines fail. Brewer is the same person who proposed the CAP conjecture in 2000. In 2008, Dan Pritchett, an architect at eBay, made the term widely known with an article called “BASE: An Acid Alternative.” He argued for relaxing ACID once a site’s data is split across many databases.

Around the same time, large web companies needed to store more data than one server could hold. Google described its Bigtable database in 2006, and Amazon described its Dynamo database in 2007. Both spread data across many servers. Other databases followed, such as Cassandra, HBase, CouchDB, and MongoDB. In 2009, Johan Oskarsson organized a meetup in San Francisco about these databases and used the name NoSQL for it. The name described databases that do not use the relational model, which is usually queried with SQL. Many of the early NoSQL databases gave up transactions across records and strong consistency so they could stay available and fast. Relational databases were built around ACID transactions. So people started to link ACID with relational databases, and BASE with NoSQL databases, including document databases.

That link is weaker today. MongoDB, the document database we chose for Shopend, has supported transactions across documents since 2018. We designed placing an order to use these transactions. Many relational databases also support replication. A relational database with replicas has the same problem we saw in this chapter: a read from a replica can return old data. Whether a system offers ACID transactions, eventually consistent reads, or both depends on how it runs transactions and coordinates its replicas, not on whether it stores tables or documents.