ACID Properties in DBMS: Atomicity, Consistency, Isolation, and Durability

ACID Properties in DBMS: Atomicity, Consistency, Isolation, and Durability

16 Apr 2025
Intermediate
2.8K Views
21 min read
Learn with an interactive course and practical hands-on labs

Free SQL Server Online Course with Certificate - Start Today

ACID stands for Atomicity, Consistency, Integrity, and Durability in database management. These are the four properties that ensure the reliability and consistency of database transactions despite failures. Popular DBMS like MySQL, PostgreSQL, and Oracle are highly ACID-compliant database systems.

Are you dealing with RDBMS? Are you interested in database or server-side programming? Do you desire to become a database administrator? Suppose any of these questions are going through your mind. In that case, this DBMS tutorial will definitely help you understand databases' transactional integrity.

Have a look at DBMS's Top 50 Most Important Interview Questions

What is Database Transaction?

A transaction in DBMS is a set of logically related operations(reads and writes). It is a single unit of work that either completes fully or does not complete at all and leaves the storage system in a consistent state. One of the most basic and familiar examples of a transaction is bank account transaction.

StateDescription
ActiveThe transaction is currently running and performing its operations.
Partially CommittedAll operations have been completed, but the final data hasn’t been saved to the database yet.
FailedThe transaction didn’t pass internal checks by the recovery system, so it’s considered failed.
CommittedThe transaction finished successfully, and all changes have been permanently saved.
AbortedThe transaction didn’t pass some checks, so it was rolled back and not saved.
TerminatedThe transaction has ended, and the system is now ready for new transactions.

When you withdraw money from your bank account through the ATM card, the following steps occur:

  1. You insert the card into the ATM
  2. You are prompted to select your preferred language
  3. You then need to choose the operation you need to perform with your bank account. Here, the operation is a money withdrawal.
  4. Then, you need to select the account type: savings or current
  5. Now you're asked for the withdrawal amount.
  6. Once you enter the amount, you are prompted to enter the ATM PIN.
  7. You enter the PIN, and after some seconds, you collect the cash and remove your card from the machine.
  8. Your bank account balance gets updated.

All the above operations are treated as a single operation in a transaction. If, at any point, the transaction fails, the entire transaction is rolled back. The database is rolled back to a state as if you had never attempted the withdrawal, thus maintaining the data integrity. The transaction is committed when all the operations within the transaction are completed and their results are permanently recorded.

Read More: SQL Server Transactions Management

The goal of logically grouping these operations in a single transaction is to make your system fault-tolerant. A transaction has different states throughout its life cycle. The states are:

Transaction States in DBMS

StateDescription
ActiveTransactions are in execution
Partially CommittedThe final operation is executed. Still, the data is not yet saved
FailedThe result of failed checks by the database recovery system
CommittedAll operations are executed successfully, and changes are permanently saved.
AbortedThe transaction fails tests, rolled back, or aborted.
TerminatedThe transaction is either committed or rolled back, effectively ending its execution.

What are ACID Properties?

Certain properties are followed before and after a transaction in a database to ensure consistency. These properties are referred to as ACID properties. The following are the expansions of ACID properties that guarantee the accuracy of every read, write, delete, and update operation on the database.

ACID Properties DBMS

1. Atomicity

This property ensures that either the transaction occurs entirely or it does not occur at all. This means that if any operation is performed on the data, it should either be performed or wholly executed or should not be executed at all. It is also referred to as the “all or nothing rule."

Any operation must not be interrupted in between or remain partially completed. If such things happen, the transaction is aborted. The Transaction Control Manager is responsible for ensuring the atomicity of the transactions.Atomicity ensures that a transaction is treated as a single, indivisible unit of work. This means:

  • All operations within the transaction are executed successfully, or none are executed.
  • If any part of a transaction fails, the database state remains unchanged by rolling back the entire transaction.

Key Operations:

  • Commit: Changes made by the transaction are permanently saved.
  • Abort: Changes made by the transaction are discarded.

Example:

    Let's understand atomicity with an example of filling out an online application form to apply for an exam.

    1. You log into the system with your username and password.
    2. Then, you fill out all the personal details, select the exam centers, and move to the application fee payment.
    3. You're prompted to select the payment method.
    4. Suppose you choose payment via debit card. You fill in all the details and click on confirm.
    5. An OTP is received on your mobile number.
    6. After you enter the OTP, the server goes down suddenly. This will fail the complete transaction. You'll again be taken to the page where you have completed filling out the exam centers. This means that the transaction rolled back completely.

    So, there is no scope for partial or incomplete transactions. Either there will be a complete failure or complete success. Without atomicity, if a failure occurs while some queries are running, it'll be challenging to find out which queries have been committed (completed) and which have not. Rerunning the queries after a failure can compound the problem since you risk introducing incorrect data to the database by re-running queries that previously succeeded.

    Atomic transactions prevent such uncertainty since you know that if the previous transaction failed, it failed in its entirety. You can retry without worrying about introducing inconsistent data.

    Read More: DBMS Viva Questions and Answers

    2. Consistency

    Consistency ensures the database remains in a valid state before and after a transaction. A transaction must preserve the integrity constraints of the database. Consistency in DBMS refers to data consistency before and after the transaction. In simple words, you always have to ensure the correctness of the database, i.e., referential integrity. Referential integrity ensures that all data is valid according to all defined rules, including any constraints, cascades, and triggers that have been applied to the database.

    Example:

    We'll take the same example of filling out the online application form to understand consistency.

    1. To make the online payment, you enter the OTP that came to your mobile.
    2. After entering the OTP, the bank server goes down, and the payment fails. This leads to the transaction being rolled back.
    3. But this isn't sufficient. The number of applicants who filled out the form for a particular exam slot must also be updated; otherwise, there will be an inconsistency where the slot given up by the person will not be accounted for.
    4. Hence, the total number of slots left in the exam center + the number of slots booked by applicants would not be equal to the total number of slots present in the center if it were not for consistency.
    MethodDescriptionPerformance ImpactUse
    TransactionsTransactions allow you to update multiple collections in one operation.This can slow down performance, especially during heavy reads.Good for apps that need to always show up-to-date data, even if it affects performance when there are many reads.
    Embedding Related DataThis means changing your schema to store related data in one collection.The performance impact is usually low to moderate, depending on document size and indexes.Great for apps that always read and update related data at the same time, and helps avoid using $lookup operations.
    Atlas Database TriggersWith Atlas Triggers, when you update one collection, it automatically updates another collection.The performance impact is usually low to moderate, but there may be small delays in updates.Useful if your app can handle slightly outdated data, as users might see old data right after an update until the trigger finishes.

    3. Isolation

    Isolation is separation. Thanks to isolation, multiple transactions can occur concurrently in a database without affecting each other. Concurrency here means two or more transactions trying to modify or read the same database record(s) at the same time or in parallel.

    Each request can appear as though it were occurring one by one, even though it's actually occurring. After concurrent transaction execution, the resultant state is the same as the state that would be achieved if the transactions were executed consecutively, one after the other.

    The user performing a transaction will not be updated about any changes made in any other transaction unless the transaction is committed. The concurrency control manager employs locking mechanisms to achieve this independence of database transactions. Isolation maintains the consistency of concurrent transactions.

    Example:

    Let's suppose there's only one seat left on a train you're looking for for your journey on the IRCTC website.

    1. You saw the one available seat and started booking it.
    2. You fill in all the details and move towards payment through UPI.
    3. After entering the UPI number, you suddenly see that the seat you selected went into the waiting category.
    4. This happened because there might have been others trying to book the same seat, but you were not aware of it.
    5. Whoever confirmed the payment first got that confirmed seat.

    Isolation in transactions gives three guarantees:

    1. No Dirty Reads: You will only see the data for the committed transaction.
    2. No Dirty Writes: You cannot overwrite data that has already been written by another transaction but has not yet been committed.
    3. Repeatable Reads: If a transaction reads a row of data, any subsequent reads of that same row of data within the same transaction will yield the same result, regardless of changes made by other transactions.

    4. Durability

    Durability means long-lasting. In the context of databases, durability refers to the fact that once the transaction is committed, the update in the database will be permanently saved. The saved changes won't be affected even if the database crashes immediately following the transaction. All committed transactions must persist on durable, non-volatile storage on disk. To ensure the durability of database transactions, one must always COMMIT the updates done to the database.

    Let's understand the importance of durability through the example of a railway management system.

    1. You booked your train tickets a month ago on IRCTC for the journey the day after tomorrow.
    2. There are no more seats on the train, as all the tickets are booked.
    3. What if, just the previous night, the railway management system crashed? All the passenger details and train details are lost.
    4. Just imagine what a significant loss and inconvenience you and other travelers will have to face. There can be other losses as well, not only financial losses.
    5. Also, a significant trust deficit will arise for the railways in the hearts of the citizens.

    To prevent such circumstances, database backups, transaction logs, and disk storage are done to ensure durability. If the railway management system had been durable, the passenger and train details would have remained intact even after the crash.

    What is another example of an ACID transaction?

    Let’s take a basic banking example where money is being transferred between two accounts. We’ll look at how each ACID property applies in this case, one by one.

    Atomicity:

    Atomicity means the money must be fully moved from one account to another. If it's taken out but not added to the other account, the data becomes incorrect.

    Consistency:

    Imagine a rule where an account balance can’t go below $0. If a transaction would make the balance negative, it should be stopped and not saved.

    Isolation:

    Imagine two money transfer requests from the same account happening at the same time. Whether they run one after another or together, the final result should be the same.

    Durability:

    If the database confirms that money was moved between accounts and then a power outage happens, the updated data should still be saved.

    Responsibility for ACID Properties

    Responsibility for ACID properties is as follows:

    PropertyManaged By
    AtomicityTransaction Manager
    ConsistencyApplication Programmer
    IsolationConcurrency Control Manager
    DurabilityRecovery Manager

    Uses of ACID Properties

    Here are some key uses of ACID properties in DBMS:

    • Keeps the database rules and structure correct and reliable.
    • Prevents issues when multiple users access or update data at the same time.
    • Allows the system to recover safely after a crash or failure.
    • Ensures the data remains accurate and consistent after each transaction.
    • Avoids saving half-completed or failed changes to the database.
    • Enforces business rules and keeps relationships between data valid.
    • Supports record tracking and helps meet legal or compliance standards.

    Advantages of ACID Properties

    • Data Integrity: Ensures that transactions are completed entirely or rolled back to prevent partial updates.
    • Consistency: Maintains database correctness by ensuring rules and constraints are preserved.
    • Concurrent Transaction Handling: Isolation allows multiple transactions to execute simultaneously without interference.
    • System Reliability: Durability ensures changes are permanently saved even during system failures.
    • Error Handling: Rolling back incomplete transactions prevents propagation of errors.
    • Enhanced Security: Isolation reduces vulnerabilities by restricting data visibility during transactions.
    • Transactional Control: Enables better predictability and debugging of database operations.

    Disadvantages of ACID Properties

    • Performance Overhead: Implementing ACID properties slows down the system, especially with high transaction volumes.
    • Complexity in Implementation: Designing a system adhering to ACID properties is resource-intensive and complicated.
    • Resource Consumption: Durability mechanisms require additional storage and processing power.
    • Scalability Issues: Strict adherence to ACID limits scalability, especially in distributed systems.
    • Concurrency Bottlenecks: Isolation mechanisms can create delays in high-transaction environments.
    • Trade-offs in Distributed Systems: Full ACID compliance in distributed databases is costly and impractical in many cases.
    • Limited Suitability for Real-Time Applications: ACID properties may be too restrictive for time-sensitive applications.
    Also Read:
    Summary

    We looked at the four fundamental principles for maintaining database integrity, consistency, and reliability. The database must be designed to adhere to these principles. An ACID-compliant database will keep a record of only successful transactions. You need to understand these basic principles in complete depth, which we have tried to explain through examples in our article. To implement your understanding, you can consider taking our SQL Server Course and MongoDB Course.

    Test your knowledge: Are you ready to challenge yourself and ace this quiz?

    SQL vs NoSQL Quiz

    Q 1: Which database type uses structured tables with rows and columns?

    • SQL
    • NoSQL
    • Both
    • None
    ScholarHat provides various Training and Certification Courses to help you in your end-to-end product development:

    FAQs

    ACID stands for Atomicity, Consistency, Integrity, and Durability in database management. These are the four properties that ensure the reliability and consistency of database transactions despite failures.

     In DBMS, ACID refers to the set of properties (Atomicity, Consistency, Isolation, Durability) that ensure reliable transaction processing, while Atomicity is the property that ensures a transaction is all-or-nothing, meaning it either fully completes or entirely fails. 

     DBMSs such as PostgreSQL, MySQL (with InnoDB), Oracle, and Microsoft SQL Server provide ACID guarantees.
    Share Article
    About Author
    Shailendra Chauhan (Microsoft MVP, Founder & CEO at ScholarHat)

    Shailendra Chauhan, Founder and CEO of ScholarHat by DotNetTricks, is a renowned expert in System Design, Software Architecture, Azure Cloud, .NET, Angular, React, Node.js, Microservices, DevOps, and Cross-Platform Mobile App Development. His skill set extends into emerging fields like Data Science, Python, Azure AI/ML, and Generative AI, making him a well-rounded expert who bridges traditional development frameworks with cutting-edge advancements. Recognized as a Microsoft Most Valuable Professional (MVP) for an impressive 9 consecutive years (2016–2024), he has consistently demonstrated excellence in delivering impactful solutions and inspiring learners.

    Shailendra’s unique, hands-on training programs and bestselling books have empowered thousands of professionals to excel in their careers and crack tough interviews. A visionary leader, he continues to revolutionize technology education with his innovative approach.
    Accept cookies & close this