Transactions in DBMS are not just “any group of database operations”; they follow a strict set of rules that guarantee correctness, reliability, and consistency. These rules are summarized in four core properties known as ACID.
Understanding ACID is essential because it explains why transactions are safe and how databases protect your data even when failures occur. We will cover each property in simple, beginner‑friendly terms; the deeper topics like concurrency control and recovery will be discussed separately.
What ACID Means
ACID is an acronym made from four properties:
A – Atomicity
C – Consistency
I – Isolation
D – Durability
Together, they describe how a transaction should behave during execution and after completion.
1. Atomicity
Atomicity means that a transaction is indivisible:
It either completes fully, or
It has no visible effect at all.
In simple terms:
“All operations in the transaction succeed, or none do; there is no partial execution.”
Why Atomicity Matters
Consider a bank transfer of ₹1000 from Account A to Account B:
Deduct ₹1000 from Account A.
Add ₹1000 to Account B.
If the system crashes after step 1 but before step 2, the database would be inconsistent if both steps were treated independently.
Atomicity ensures that either both steps are applied (commit) or both are canceled (rollback). The DBMS uses logging and rollback mechanisms to undo partial changes when a transaction cannot finish.
Key Idea
Atomicity = All‑or‑nothing behavior of a transaction.
It protects the database from half‑done operations.
2. Consistency
Consistency means that a transaction must take the database from one valid state to another valid state.
In other words:
Before the transaction starts, the database is in a correct, consistent state.
After the transaction finishes (if it commits), the database is still in a correct, consistent state.
What “Consistent” Means
“Consistent” here includes:
Data integrity constraints (primary key, foreign key, unique constraints).
Business rules (for example, account balance must not be negative).
Logical rules (for example, the total money in the system must not change in a bank transfer; only the distribution among accounts changes).
If a transaction would violate any of these rules, it must be rejected or rolled back so that the database never moves into an invalid state.
Example
Suppose the total money in a bank system is ₹10,000 before a transfer of ₹1000 from Account A to Account B. After the transfer, the total must still be ₹10,000.
If the transaction somehow made the total ₹11,000 (due to a programming or logic error), it would break consistency, and the transaction must not be allowed to commit.
Key Idea
Consistency = Valid state → Valid state.
The DBMS checks constraints and rules to ensure this at every transaction boundary.
3. Isolation
Isolation means that even if multiple transactions run at the same time, they should not interfere with each other in a way that makes the database inconsistent.
In simple terms:
Each transaction should behave as if it were running alone, at least from a logical point of view.
Why Isolation Is Needed
Consider two users trying to withdraw money from the same account at the same time:
User 1 reads the balance and starts a withdrawal.
User 2 also reads the balance and starts another withdrawal.
If both use the same initial balance without coordination, one or both withdrawals may be applied incorrectly, leading to over‑withdrawal or negative balance.
Isolation ensures that:
Transactions do not read or write overlapping data in a harmful way.
Conflicting operations are properly scheduled or locked so that the final result is correct.
Levels of Isolation (Concept Only)
Different DBMS products support isolation levels like:
Read Committed
Repeatable Read
Serializable
These levels control how much one transaction can “see” of another’s uncommitted changes. A detailed discussion of isolation levels and locking will be covered in the concurrency control article.
Key Idea
Isolation = Safe concurrent execution of transactions.
It prevents interference between transactions that would break consistency.
4. Durability
Durability means that once a transaction is committed, its changes are permanent and must not be lost, even if the system crashes immediately after.
In simple terms:
“If I see that the transaction is committed, then the data is safely saved, no matter what happens next.”
How Durability Is Achieved
Durability is usually implemented using:
Transaction logs:
Before writing changes to the main database, the DBMS writes them to a log file on stable storage.Write‑ahead logging (WAL):
The rule is: log the change before updating the actual data.Recovery mechanism:
After a crash, the DBMS replays the log to redo committed transactions and undo uncommitted ones.
Example
In a bank transfer:
Once the transfer is committed, the new account balances are recorded in the log.
Even if the system crashes right after, the recovery process will re‑apply the transfer when the database restarts, so the money is not lost.
Key Idea
Durability = Committed changes are permanent.
It gives applications confidence that saved data will survive failures.
How ACID Properties Work Together
Atomicity ensures that each transaction is treated as a single, indivisible unit.
Consistency ensures that the database stays logically correct before and after the transaction.
Isolation ensures that multiple transactions running at the same time do not break each other’s logic.
Durability ensures that once a transaction is committed, its changes survive system failures.
Together, these four properties make transactions safe, reliable, and predictable, which is why they are the foundation of any serious database system.
Summary
ACID properties in DBMS define the core behavior of transactions:
Atomicity ensures all‑or‑nothing execution.
Consistency ensures movement from one valid state to another.
Isolation ensures safe concurrent execution of transactions.
Durability ensures that committed changes are permanent, even after crashes.
Understanding ACID helps you see why transactions are trustworthy and forms a strong base for later topics like transaction lifecycle, concurrency control, and recovery.