Working with databases we often see the flashy headline on the websites of database vendors claiming their database is ACID compliant. Sure, we do learn a thing or two about ACID properties in Database courses as well. Let's take a peak into what is actually possible and if the ACID claims really fits all the time?
It all comes down to the concept of transaction and if we assume that the idea of database executing a transaction was not there then ACID would not really mean anything.
Transaction means that if I tell the database to perform an operation then it is not considered done until it is fully completed and committed. Consider an example where you tell the database to give your top 5 users a discount of 10% and it goes ahead updating the records in the table. If due to any reason all 5 users are not updated, the transaction will not be completed and it will be considered as if no update request was ever recorded. The database should stand at where it was before the user executed the command.
If you grasp the idea of a transaction then understanding the 4 properties in the acronym of ACID becomes simple. So let's take a look one by one.
1- Atomicity
In chemistry terms we an atom is an entity which is the smallest possible unit (well not true entirely because we know about neutrons, protons, electrons etc. etc. but lets just assume it is). When we say that a database is Atomic it simply implies that any operation executed will be treated as an indivisible unit which will mean all or nothing. It is exactly what is discussed above when we were talking about a transaction.
2- Consistency
This one is a bit controversial. Lets discuss why I say that. Consistency in simpler terms mean that our data is always in a state of correct condition. We discussed earlier that databases that support transactions already ensures that operations performed always follow "all or nothing" sort of pattern. How come consistency come into picture when atomicity is already there for a low level guarantee. If we think carefully then maintaining and ensuring consistency usually falls into the responsibility of the application. Database is keeping its promise of keeping its state perfect but its up to us to provide that data. If I don't keep the correct track of invariants(constraints) then eventually the data stored will be inconsistent. We cannot put the burden of our definition of consistency onto the database even though it gives us the ability to put those checks to maintain a state of data stored onto it.
3- Isolation
The guarantee that an operations is done in a manner such that it treats itself as the only operation happening at the moment is called Isolation. Lets simplify this. In case of reading and updating a value, a transaction will assume that there is no other transaction meddling with this data. Database providers use different techniques to achieve this and there are several levels they use to support isolation. It is indeed a challenging task and there are various studies on this. We can discuss in a different article.
4- Durability
It is simply the promise that anything assumed to have been given to the database will be considered available and logged onto it. It would not be the expectation that we give something (execute a command to insert a record in a table) to it and we are not able read it back. The database who is ACID compliant will make sure of the durability and will take care of the reads and writes properly getting committed onto permanent disks without any problems.
Conclusion
The much advertised ACID compliance of databases is less of a flashy feature and more of a set of fundamental promises that make reliable data systems possible. Atomicity, Consistency, Isolation, and Durability together form the foundation, but they are not magic bullets because application design will still play a significant role in keeping data truly meaningful. A database may guarantee transactions and durability, but it is up to us to define the right invariants and enforce them correctly. Understanding what each property really means allows us to better appreciate where the database ends and where our responsibility begins. With this clarity, ACID stops being just an acronym and becomes a practical guide for building dependable systems.
Top comments (1)
I actually understood ACID properly after reading this