Not having ACID properties means that the database works well on clusters. But ACID is something very fundamental. How can a database work well if there is no atomicity, consistency, isolation and durability (ACID)?


How can a database work well if there is no atomicity, consistency, isolation and durability?

They can't. This is why those features were created.

Sometimes you can work around the lack of these features because you need to scale horizontally or scaling becomes your first and primary concern. You may not need need consistency now, you may be able to handle it later.. You may not need all the data returned in order: you may want the queries executed in parallel over clusters. Or your data may itself be fairly un-valuable.

Look at major products that implement these types of systems though -- generally, they suck and they have lots of errors. Ever post something to your wall on Facebook just to see it disappear and reappear multiple times? Or to have a conversation you're commenting on vanish for an extended period of time and come back? That's hundreds of people working to manage data using "NoSQL" and compiling PHP to C++. It doesn't especially work well. It works, and for most companies that's further than they can get developing an alternative.

  • 1
    What does PHP compiling to C++ have anything to do with this? – Chris Stryczynski May 25 '20 at 18:20

Not having ACID properties means that the database works well on clusters. But ACID is something very fundamental. How can a database work well if there is no atomicity, consistency, isolation and durability (ACID)?

I am not discarding anything of Vérace,Evan Carroll & Randolph West.

According to this blog, in his presentation NoSQL: Past, Present, Future Eric Brewer presents a particularly fine section on explaining the often hard to understand ideas of BASE (Basically Available, Soft State, Eventually Consistent).

I would not also say here more about that How can a NoSQL database work well if there is no atomicity, consistency, isolation and durability (ACID)?. Because it will be too early to say on this junction , as per my professional dba knowledge.

But I want to share with you the DataStax CEO Billy Bosworth's article from the InfoWorld New Tech Forum: "Top 5 misconceptions about ACID compliance in a nonrelational world." which may help you.

Misconception No. 1: You can't build an online application without ACID compliance

Misconception No. 2: ACID is an all-or-nothing proposition

Misconception No. 3: Eventual consistency violates the "C" in "ACID"

Misconception No. 4: Databases and applications have a 1:1 relationship, so it's either/or between relational and NoSQL technologies

Misconception No. 5: NoSQL databases are for "Web scale" applications only; everything else uses ACID-compliant technology

Why it matters by Eric Brewer has continued to refine his understanding of the CAP (Consistency, Availability, Partition Tolerance) theorem in light of new technologies. At the same time, developers, architects, and database administrators are advancing their understandings of such trade-offs. At least, they're realizing we don't live in a one-size-fits-all world and must employ the right technologies for the right job. Those who free their minds of relational misconceptions will harness the power and opportunity provided by this new world of diverse database technologies.

For further reference:

  • 1
    "relational misconceptions"? What is that supposed to mean? – ypercubeᵀᴹ Sep 13 '17 at 9:06
  • @ypercubeᵀᴹ, As per Eric Brewer ,he has taken misconception based on modern web application with NoSQL databases. – Md Haidar Ali Khan Sep 13 '17 at 9:47
  • 1
    "Those who free their minds of relational misconceptions". Next, "physicists who free their minds of natural misconceptions." – I Support The Boycott Sep 13 '17 at 15:39

The big thing about NoSQL is the concept of "eventual consistency" or "optimistic replication".

Assuming nothing in the database is really dependent on the order of inserts, modifications or deletes, it vastly improves performance.

After all, performance is a feature.


In a nutshell, a higher isolation level leads to more scenarios where two transactions cannot execute concurrently. It also makes providing higher availability harder. The whole point of horizontal scaling is to add concurrency and availability. The whole point of NoSQL was to provide a model which is easy to scale horizontally. ACID conflicts with these goals.

As a concrete example, imagine a horizontally scaled cluster running some ACID compliant database. What if two transactions are doing a bulk update on intersecting ranges within a table and both ranges touch data on more than one node in the cluster. However the cluster is architected, the two nodes will have to communicate with each other. They need to agree on who gets certain locks to ensure Isolation. They need to agree on exactly what data was there before each transaction started to provide roll back functionality (needed for consistency and atomicity).

Not only does this add overhead which eats into the cluster's capacity, it involves locks preventing full concurrency. Lastly, if one of the nodes is down, neither transaction should complete successfully - preventing availability. We've succeeded in negating the availability and concurrency we gained by having more than one node in the first place.

It is worth noting that NoSQL databases do provide ACID to various degrees. Some even goes as far as being fully ACID compliant so long as a transaction only touches one node.


Before people see the word "cluster" and think that this must be the next "New Thing" and therefore it must be "A Good Thing (tm))", just take a read of Ted Dziuba's article here. The title might give you some clue as to his take on NoSQL databases.

NoSQL databases are not ACID, they are BASE (*)! Basically Avaiable, Soft state, Eventually consistent! What this means is that, if say Amazon used this, you would always be able to "purchase" a book from them with no guarantee as to whether there was stock available to fullfill your order! They are an attempt to "beat" Brewer's theorem! Well, guess what Jim? "Ye cannae beat the laws 'ah physics Jim!" (with apologies to Gene Roddenberry :-)).

Michael Stonebraker really is a man to listen to when it comes to database technology, being successful both on the academic and commerical fronts.

He agrees with the fundamental premise of NoSQL that what he terms OldSQL is broken! He just argues (forcibly) that throwing out ACID guarantees is literally throwing the baby out with the bathwater.

What he argues for is ACID compliant databases without all the locking and transactional overhead of systems like Oracle, MS SQL Server, PostgreSQL and MySQL inter alia. He also suggests that they should be sent to the "home for retired software" :-)!

How, you may ask? Well, two ways:

His point about NewSQL is that for OLTP apps, you need a shared-nothing sharded architecture (check out his VoltDB - based on HStore) and that for OLAP you need dedicated columnar stores, i.e. Vertica (based on CStore, which he sold to HP).

To answer the actual question directly: "Why are nosql databases not acid compliant" is because they weren't designed to be. ACID is a lot of work and requries lots of resources in the machine, but even Google are being forced to go back to ACID and SQL!

NoSQL is an attempt to wriggle out of fundamental constraints and, as a result, will fail. That is not to say that it won't have a niche in certain areas, but it will always be just that, niche!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.