Neo4j Blog

Graph Databases for Beginners: ACID vs. BASE Explained

When it comes to NoSQL databases, data consistency models can sometimes be strikingly different than those used by relational databases (as well as quite different from other NoSQL stores).
The two most common consistency models are known by the acronyms ACID and BASE. While they’re often pitted against each other in a battle for ultimate victory, the fact remains that both consistency models come with advantages – and disadvantages – and neither is always a perfect fit.
In this “Graph Databases for Beginners” blog series, I’ll take you through the basics of graph technology assuming you have little (or no) background in the space. In past weeks, we’ve tackled why graphs are the future, why data relationships matter, the basics (and pitfalls) of data modeling, why a query language matters and why we need NoSQL databases.
This week, we’ll discuss the key differences between ACID and BASE data consistency models and what their various trade-offs and advantages mean for your database transactions.

The ACID Consistency Model

Many developers are familiar with ACID transactions from working with relational databases. As such, the ACID consistency model has been the norm for some time.
The key ACID guarantee is that it provides a safe environment in which to operate on your data. The ACID acronym stands for:
Atomic

All operations in a transaction succeed or every operation is rolled back.

Consistent

On the completion of a transaction, the database is structurally sound.

Isolated

Transactions do not contend with one another. Contentious access to data is moderated by the database so that transactions appear to run sequentially.

Durable

The results of applying a transaction are permanent, even in the presence of failures.

ACID properties mean that once a transaction is complete, its data is consistent (tech lingo: write consistency) and stable on disk, which may involve multiple distinct memory locations.
Write consistency can be a wonderful thing for application developers, but it also requires sophisticated locking which is typically a heavyweight pattern for most use cases.
When it comes to NoSQL technologies, most graph databases (including Neo4j) use an ACID consistency model to ensure data is safe and consistently stored.

The BASE Consistency Model

For many domains and use cases, ACID transactions are far more pessimistic (i.e., they’re more worried about data safety) than the domain actually requires.
In the NoSQL world, ACID transactions are less fashionable as some databases have loosened the requirements for immediate consistency, data freshness and accuracy in order to gain other benefits, like scale and resilience.
(Notably, the .NET-based RavenDB has bucked the trend among aggregate stores in supporting ACID transactions.)
Here’s how the BASE acronym breaks down:
Basic Availability

The database appears to work most of the time.

Soft-state

Stores don’t have to be write-consistent, nor do different replicas have to be mutually consistent all the time.

Eventual consistency

Stores exhibit consistency at some later point (e.g., lazily at read time).

BASE properties are much looser than ACID guarantees, but there isn’t a direct one-for-one mapping between the two consistency models.
A BASE datastore values availability (since that’s important for scale), but it doesn’t offer guaranteed consistency of replicated data at write time. Overall, the BASE consistency model provides a less strict assurance than ACID: data will be consistent in the future, either at read time (e.g., Riak) or it will always be consistent, but only for certain processed past snapshots (e.g., Datomic).
The BASE consistency model is primarily used by aggregate stores, including column family, key-value and document stores.

Navigating ACID vs. BASE Trade-offs

There’s no right answer to whether your application needs an ACID versus BASE consistency model. Developers and data architects should select their data consistency trade-offs on a case-by-case basis – not based just on what’s trending or what model was used previously.
Given BASE’s loose consistency, developers need to be more knowledgeable and rigorous about consistent data if they choose a BASE store for their application. It’s essential to be familiar with the BASE behavior of your chosen aggregate store and work within those constraints.
On the other hand, planning around BASE limitations can sometimes be a major disadvantage when compared to the simplicity of ACID transactions. A fully ACID database is the perfect fit for use cases where data reliability and consistency are essential.
In the next two weeks we’ll dive into more ACID/BASE specifics when it comes to aggregate stores and other graph technologies.
Want to learn more about graph databases? Click below to get your free copy of the O’Reilly Graph Databases ebook and discover how to apply graph solutions to mission-critical problems at your enterprise.

About the Author

Bryce Merkl Sasaki,
Aspiring Graphista

Bryce Merkl Sasaki is the Community Content Manager for Neo Technology. He studied professional and creative writing for undergrad and has been freelancing for 7 years. Recently, he worked at an inbound marketing agency in Philadelphia as a copywriter before moving to California. When not working, he likes to spend his time working on his novel, looking for pickup soccer games and reading voraciously.

1 Comment

Hilarious!
For whatever reason I needed a reminder of the difference between an acid and a base (it’s the proton exchange … the second result told me…) and what comes up in Google? Your page on database consistency models.
You must be a master of SEO to beat out every chemistry site on the planet to be the number one spot for the search term “acid vs base”. Though we do know that Google is aware of our past searches and I have a background in DB and have done active searches in that arena…but hey…this is just too good of an SEO job.
Bravo to you sir!

This website uses 'cookies' to give you the best, most relevant experience. Using this website means you’re OK with this. You can change which cookies are set at any time - by clicking on more info. Accept