When discussing databases, the most common question you will hear is asking whether it is ACID compliant. But what even is ACID? Well, ACID stands for atomicity, consistency, isolation, and durability. It describes a set of expectations that ensure any database transactions are processed in a reliable way, resulting in correctness. A database is considered ACID-compliant when it meets these expectations or principles.
In this article, you will learn more about what ACID means, breaking down the four elements in more detail, and why it’s so important.
Table of contents
In this section, we will dive more into what the four elements of ACID are, and what role they play in ensuring reliability of data transactions.
Atomicity is all based around this idea of togetherness. When carrying out any kind of database transaction, it often consists of multiple operations. With atomicity, either every operation succeeds or none of them do. This is important because the operations can have an impact on each other, so one failing can lead to unexpected results.
Think of a financial transaction, for example. You are paying a friend $250 for a holiday you are going on. The whole transaction would consist of the money leaving your account and arriving in the recipient’s account. If there was no atomicity, it is possible that money leaves your account but doesn’t arrive at the other end, resulting in you being debited the money but still owing the recipient.
Consistency is about ensuring that changes made as part of a transaction are consistent with any database constraints. If the data at any stage goes against these constraints, the whole transaction will fail.
Unless you have an agreed overdraft, banks, for example, will expect your balance to be positive. So if you tried to withdraw more money than you have available, this would break a constraint and fail, rolling back all operations in that transaction.
Isolation is there to make sure that all transactions are run in an isolated environment without interfering with each other.
Sticking with the financial example, imagine you have a bank balance of $200 and you try to withdraw $100 at an ATM. At the same time, a standing order you have set up comes out for $100. With isolation, these transactions can occur concurrently, ensuring that your ending balance is $0, not $100, because the transactions impacted each other.
Durability is another important element of ACID because it ensures that no matter what happens, once a transaction is complete, the changes in that transaction are written to the database. This makes sure that data changes are persisted, even in the event of a power failure or system crash.
As mentioned above, ACID is all about ensuring data will be in an expected, consistent state after running a group of operations, aka a transaction. So, a transaction that adheres to the elements of ACID is called an ACID transaction.
ACID has been something many relational databases have offered for a while. This means that when deciding whether to migrate to a NoSQL solution, people often ask, “Can NoSQL databases be ACID-compliant?” Well, the answer is simple: Absolutely! Not every single NoSQL database is ACID-compliant, but many are. In fact, MongoDB is an ACID-compliant database. As of MongoDB 4.0, there is even support for multi-document ACID transactions when required. Version 4.2 even brought distributed multi-document ACID transactions for even more flexibility.
However, MongoDB’s data modeling best practice suggests storing related data together in a single document using a variety of data types, including arrays and embedded documents. So, a lot of the time, ACID is not required as it is a single-document transaction.
Another term you will sometimes hear is BASE, which is an acronym that (kind of) stands for Basically Available, Soft State, Eventually Consistent. With BASE, availability is prioritized over consistency. This was originally developed for NoSQL databases that weren’t able to be ACID-compliant. This is no longer the case, though, and ACID is definitely the most desired. MongoDB, for example, cannot be BASE-compliant because transactions are consistent and not eventually consistent, as per the rules of BASE.
In this article, you have learned a little bit about what ACID is, why it is important, and how MongoDB is fully ACID-compliant. You also saw how ACID transactions are a core part of databases and MongoDB is able to meet this via multi-document and distributed multi-document transactions.
Get started today using MongoDB Atlas and enjoy the rich document-data model and ACID-compliant features.
Yes! MongoDB is fully ACID-compliant with ACID transactions. Taking advantage of the document-data model and storing related data together negates the need for transactions. But in the event they are required, MongoDB supports multi-document and distributed multi-document ACID transactions.
ACID stands for Atomic, Consistent, Isolated, Durable and refers to a set of principles around how data transactions will be treated, allowing for high reliability and correctness. In the event any operation in a transaction cannot be completed, the transaction will fail and the changes will be rolled back.
Although not strictly compulsory, it is recommended to use a database such as MongoDB that is ACID-compliant because it allows for confidence that the data in your database is correct and has not been impacted by any other transactions or unexpected system issues.