What is ACID Compliance?

ACID stands for Atomicity, Consistency, Isolation and Durability. In other words, data integrity! Relational databases have long established ACID as a best practice; however, the distributed nature of NoSQL makes ACID difficult to fully achieve. Let's dive into the components of ACID:

Atomicity 

Either the entire transaction runs or it doesn’t at all. This is crucial in the event your updates or inserts fail midway. Most databases offer this transparently with single operations; however, transactions are typically used for series of operations that require Atomicity.

Consistency

This one seems obvious, but your database needs to function properly before and after any operation you perform. Simply put, nothing you do should corrupt your data or database. As for the exact rules enforced to ensure consistency, that’s based on the type of database. Even document databases have rules and checks put in place—as limited as they are.

Isolation

Isolation means any transactions will behave the same no matter what other operations may be running at that same time. Databases that enforce Isolation guarantee that if multiple queries are running concurrently, they will behave the same as if they were ran sequentially. Isolation is generally achieved by hiding the results of unfinished transactions until the transaction is fully committed.

Durability

Simply put, once a transaction is committed its guaranteed to persist even in the event of a crash or outage. Databases often achieved this by storing information on non-volatile memory such as a hard drive or solid-state drive. Durability can also be improved upon with data replication—a feature available to most databases.

Is NoSQL ACID Compliant?

The short answer.... sort of. Technically speaking each operation against a NoSQL database is ACID compliant. For the longest time NoSQL has justified it's lack of fully adopting ACID compliance by viewing the individual command as the atomic unit itself. The problem with this thought process is most real-world applications require Atomicity across multiple database commands.

Is ACID Really That Important?

Let's say for instance you have a process that is responsible for handling new user registration. Your service might do several things such as 1) creating a new user followed by 2) creating a contact for that user and then finally 3) creating a subscription for that user. If for some reason the subscription creation fails, it would necessary to revert or rollback the first to inserts. For the longest time this type of multi-command transaction was impossible in the NoSQL world. That was until....

MongoDB Gave Us ACID

In 2018 MongoDB finally gave into the pressure and officially introduced multi-document transactions. As much as MongoDB may have wanted to downplay this move, this update gave the world the first ever fully ACID compliant NoSQL database.

When asked about the significance of this feature, MongoDB co-founder and CTO Eliot Horowitz made it a point to emphasize that he doesn’t believe developers will enable this new feature default, and that most will only enable it for very specific use cases.

Regardless how many existing MongoDB users will take advantage of this feature, knowing that MongoDB supports multi-document transactions makes moving to NoSQL a less intimidating thought.

Tell us your thoughts on MongoDB supporting multi-document transactions on twitter @meshydb.com!

We wrote a great article that goes into detail on MongoDB our blog on what is nosql?. We suggest checking that out if you are interested in or considering a NoSQL.