ACID Properties in Database

ACID is an acronym and mnemonic way for learning and remembering the four primary attributes that are essential for any sorts of database transaction. The acronym stands for Atomicity, Consistency, Isolation, and Durability. ACID model sets forward four goals that every database management system must strive. It allow safe sharing of data. It is basically a set of properties that guarantee that database transactions are processed reliably. Any database that fails to meet any of these four goals can’t be considered reliable.

Example:  Every transaction that we occur in online where some sorts of computer systems involved follow the ACID principle. If there were no ACID principle were involved then each transaction would be difficult and the potential for inaccuracy would be huge. Imagine more than one person trying to buy the same size and color of a particular dress at the same time, without ACID principle the transaction more likely to be inconsistent.

Let me explain the acronym.


Atomicity means that the system ensures/guarantee that all of a transaction happens, or none of it does. In atomicity you have to consider the whole task as one single unit. If any portion(or sub-portion) fails at any step it will roll back to the place where it starts from. Database modifications must follow an all or nothing rule.

“Each transaction is said to be atomic only if any part of the transaction fails turns the entire transaction to fail.”


Consistency means that your system ensures/guarantee that your data will be consistent after your first commit. What I mean by this is that even after any insert, update command which directly hits your database will ensure that the database remains in a consistent state before the start of the transaction and after the transaction is over , even if its unsuccessful. If a transaction is executed that violates the database’s consistency rules, the entire transaction will be rolled back and the database will be restored to a state consistent with those rules. On the other hand, if a transaction successfully executes, it will take the database from one state that is consistent with the rules to another state that is also consistent with the rules.

For example, in a ticket counter there is an inconsistent view of how many movie ticket is truly available for purchase, if inventory is allowed to fall below 0, making it impossible to provide more than an intent to complete a transaction at checkout time.

A distributed data system is either strongly consistent or has some form of weak consistency. Weak consistency is sometimes referred to as eventual consistency, the database eventually reaches a consistent state. Weak consistency systems are usually ones where data is replicated; the latest version is sitting somewhere in the cluster, older versions are still out there. Eventually all nodes will see the latest version. At the other end of the spectrum is BASE (Basically Available Soft-state Eventual consistency).


Isolation means that one transaction cannot read data from another transaction that is not yet completed. If two transactions are executing concurrently, each one will see the world as if they were executing sequentially, and if one needs to read data that is written by another, it will have to wait until the other is finished. For say, if Mr. X issues a transaction against a database at the same time that Mr. Y issues a different transaction, both transactions should operate on the database in an isolated manner. The database should perform those transaction one after another. This prevents them reading intermediate data produced by another transaction. Note that the isolation property does not ensure the order of transactions i.e. it does not ensure which transaction will execute first.

For example, user A withdraws $100 and user B withdraws $250 from user Z’s account, which has a balance of $1000. Since both A and B draw from Z’s account, one of the users is required to wait until the other user transaction is completed, avoiding inconsistent data. If B is required to wait, then B must wait until A’s transaction is completed, and Z’s account balance changes to $900. Now, B can withdraw $250 from this $900 balance.

Isolation refers to the requirement that other operations cannot access or see the data in an intermediate state during a transaction.


Durability refers to the guarantee that once the user has been notified of success, the transaction will persist, and not be undone. This means it will survive system failure, and that the database system has checked the integrity constraints and won’t need to abort the transaction. Durability is ensured through the use of database backups and transaction logs that facilitate the restoration of committed transactions in spite of any subsequent software or hardware failures. Many databases implement durability by writing all transactions into a transaction log that can be played back to recreate the system state right before a failure.

Once a transaction is complete, it is guaranteed that all of the changes have been recorded to a durable medium (such as a hard drive, solid state drive etc)

The ACID concept is described in ISO/IEC 10026-1:1992 Section 4. You can check there for details.