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 (please someone make a video of that), both consistency models come with advantages – and disadvantages – and neither is always a perfect fit.
Let’s take a closer look at the trade-offs of both database consistency models.
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 graph technology is the future, why connected data matters, the basics (and pitfalls) of data modeling, why a database query language matters, the differences between imperative and declarative query languages, predictive modeling using graph theory, the basics of graph search algorithms and why we need NoSQL databases.
This week, we’ll take a closer look at the key differences between ACID and BASE database consistency models and what their trade-offs mean for your data 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:
- All operations in a transaction succeed or every operation is rolled back.
- On the completion of a transaction, the database is structurally sound.
- Transactions do not contend with one another. Contentious access to data is moderated by the database so that transactions appear to run sequentially.
- The results of applying a transaction are permanent, even in the presence of failures.
Write consistency is 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 database 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:
- The database appears to work most of the time.
- Stores don’t have to be write-consistent, nor do different replicas have to be mutually consistent all the time.
- Stores exhibit consistency at some later point (e.g., lazily at read time).
A BASE data store 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 (banking, anyone?).
In the coming weeks we’ll dive into more ACID/BASE specifics when it comes to aggregate stores and other graph technologies.
Get your copy of the O’Reilly Graph Databases book and start using graph technology to solve real-world problems.
Get the Book
Catch up with the rest of the Graph Databases for Beginners series:
- Why Graph Technology Is the Future
- Why Connected Data Matters
- The Basics of Data Modeling
- Data Modeling Pitfalls to Avoid
- Why a Database Query Language Matters (More Than You Think)
- Imperative vs. Declarative Query Languages: What’s the Difference?
- Graph Theory & Predictive Modeling
- Graph Search Algorithm Basics
- Why We Need NoSQL Databases
- A Tour of Aggregate Stores
- Other Graph Data Technologies
- Native vs. Non-Native Graph Technology
About the Author
Bryce Merkl Sasaki , Editor-in-Chief, Neo4j
Bryce Merkl Sasaki is the Editor-in-Chief at Neo4j. 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.