This post is sponsored by NuoDB.
All thoughts and opinions are my own.
When moving an on-premises app to the cloud, software vendors may find the lack of ACID in the database and – therefore the need to code data management functionality into the application – an insurmountable challenge.
This blog continues the series on the top four considerations for choosing the database for software vendors moving to a SaaS business model. In addition to the importance of SQL functionality and true elasticity, there is the importance of ACID. For certain types of applications, eliminating ACID and having to code data management functionality into the application instead of letting the database take care of it creates substantial complications.
ACID stands for atomicity, consistency, isolation, and durability. Compliance to ACID means that a system supports transactions by guaranteeing the full committal of all or no operations in a transaction. This ensures the state of the system is always consistent. In a banking scenario, if I only commit the deposit and the associated withdrawal does not complete, not only is the system inconsistent, but it could be difficult to restore consistency.
Expanding on this (since ACID stands for 4 distinct items, not one), we have…
- Atomicity – All operations or no operations of a transaction committed – no in between
- Consistency – The database only has valid and committed transactions
- Isolation – No views into components of uncommitted transactions
- Durability – Committed transactions are permanent, and a restore will contain all committed transactions
A significant number of the offerings in the NoSQL and Commercial open source (OSS) camps are fundamentally different from what a Fortune 50 may be used to when it comes to ACID compliance. So is the lack of ACID compliance a fault in the design or is there a time and place for tools short of ACID compliance?
Nearly the entire NoSQL movement has emerged by playing up the benefits of non-ACID compliance (and taking advantage of the speed of development) such that it’s almost by definition that NoSQL is not ACID compliant. I do note that some do provide ACID compliance using eventual consistency and others promote processes and have ACID-light features like “lazy writes” to minimize inconsistencies.
The NoSQL movement plays to the importance of the applications it serves. It serves a different class of applications than has been tapped to-date with relational database technologies.
Moreover, many relational applications rely on a strict level of consistency not offered by even the ACID-compliant, eventually consistent NoSQL databases. We should be careful that non-ACID and eventually consistent databases do not step over the line into areas the technology is not suited for. One way to sum this up is the confession of a leading engineer of a product that he wouldn’t use NoSQL for “money.”
ACID compliance has a psychological side as well. ACID provides a greater comfort level to developers and managers, knowing that data will not be lost no matter what and that all kinds of data can be trusted to the database.
As operational applications (especially with those dealing with valuable and even business-critical data) increasingly move to the cloud, they often need a database that can combine strict ACID compliance with the elastic scale out and availability advantages that caused people to turn to NoSQL in the first place. Finding an elastic SQL database – like NuoDB – that preserves ACID while providing that elasticity and availability is a valuable alternative for a software vendor moving to SaaS.
This post is sponsored by NuoDB. All thoughts and opinions are my own.