ACID properties are four rules — Atomicity, Consistency, Isolation, and Durability — that make sure a database transaction always runs safely and correctly, even if there is an error, a crash, or many transactions running at the same time. For IBPS SO IT Officer, you mostly need to know what each property means and how to tell them apart in MCQs. You don't need to memorize technical definitions word-for-word.
Fast Memory Trick: Atomicity = All or Nothing · Consistency = Valid State to Valid State · Isolation = Transactions Don't Clash · Durability = Once Saved, Always Saved
What Are ACID Properties?
A transaction is one unit of work in a database, like transferring money from one account to another. ACID properties are the rules that make sure this unit of work is trustworthy.
Example: Suppose Rahul sends ₹100 from Account A to Account B. This involves two steps:
- Subtract ₹100 from Account A.
- Add ₹100 to Account B.
The database should never end up in a state where the money leaves Account A but never reaches Account B. This is exactly the kind of problem ACID properties are designed to prevent.
Quick Revision
- ACID = Atomicity, Consistency, Isolation, Durability.
- These four properties make transactions reliable, safe, and predictable.
- Each property protects against a different kind of failure.
1. Atomicity — All or Nothing
Atomicity means a transaction is treated as one single, indivisible unit: either every operation in it succeeds, or none of them do.
In the bank transfer example, if the debit from Account A succeeds but the credit to Account B fails, Atomicity requires the database to undo the debit as well. The transaction cannot be left "half done."
Q: What happens if a transaction fails halfway through? A: If Atomicity is followed, the database automatically rolls back any changes already made by that transaction, so it looks like the transaction never happened at all.
Do not confuse Atomicity with Isolation. Atomicity is about one transaction finishing completely or not at all. Isolation is about how different transactions behave when they run at the same time.
Quick Revision
- Atomicity = all steps succeed, or none do.
- If any step fails, the whole transaction is rolled back.
- Exam keyword: "partial transaction" or "some steps fail" → think Atomicity.
2. Consistency — Valid State to Valid State
Consistency means a transaction can only move the database from one valid state to another valid state, without breaking any of its rules.
These rules include things like:
- Primary key rules
- Foreign key rules
- Data type and format rules
- Any business rules the database must follow
Q: Does Consistency mean users always see the latest data? A: No. That idea is closer to Isolation. Consistency is about the database always following its own rules and constraints, not about which version of the data a user happens to see.
Quick Revision
- Consistency = the database stays correct before and after every transaction.
- It protects rules like primary keys, foreign keys, and data types.
- Exam keyword: "valid state," "integrity," or "rules preserved" → think Consistency.
3. Isolation — Transactions Don't Clash
Isolation means transactions running at the same time should not interfere with each other, and each transaction should behave as if it were running alone.
When Isolation is weak, three common problems can occur:
| Problem | What Happens |
|---|---|
| Dirty Read | A transaction reads data that another transaction has not committed yet |
| Non-Repeatable Read | Reading the same row twice in one transaction gives two different values |
| Phantom Read | Running the same query twice returns a different set of rows |
If a question mentions concurrent transactions, dirty reads, non-repeatable reads, or phantom reads, the answer is almost always Isolation.
Isolation Levels
SQL databases offer different isolation levels. Stronger levels give better protection but can slow down the system, because they allow less overlap between transactions.
| Isolation Level | What It Prevents | Strength |
|---|---|---|
| Read Uncommitted | Nothing — dirty reads can still happen | Weakest |
| Read Committed | Dirty reads | Low |
| Repeatable Read | Dirty reads and non-repeatable reads | High |
| Serializable | Dirty reads, non-repeatable reads, and phantom reads | Strongest |
Q: Which isolation level gives the strongest protection? A: Serializable gives the strongest protection, because it prevents dirty reads, non-repeatable reads, and phantom reads, though it also allows the least concurrency among transactions.
Quick Revision
- Isolation = transactions don't step on each other's toes.
- Weak isolation causes dirty reads, non-repeatable reads, and phantom reads.
- Isolation levels, weakest to strongest: Read Uncommitted → Read Committed → Repeatable Read → Serializable.
4. Durability — Once Saved, Always Saved
Durability means that once a transaction is committed, its changes are saved permanently and will survive even a system crash right after.
Databases achieve this using techniques like logging and writing data to stable storage, so committed changes are never lost.
Q: What is the difference between Atomicity and Durability? A: Atomicity is about whether a transaction completes fully or not at all, and it applies before the transaction is committed. Durability is about whether the changes stay saved after the transaction has already been committed, even through a crash.
Quick Revision
- Durability = committed data can never be lost.
- It applies only after a transaction has been committed.
- Exam keyword: "COMMIT followed by a crash" → think Durability.
ACID Properties in One Example
Here's how all four properties apply to the same ₹100 transfer from Account A to Account B.
| Property | What It Guarantees in This Example |
|---|---|
| Atomicity | The debit and the credit both happen, or neither happens |
| Consistency | The total money in the system stays correct and all rules are followed |
| Isolation | Another transaction reading these accounts does not see a half-finished transfer |
| Durability | Once the transfer is committed, it stays saved even if the system crashes right after |
ACID Properties vs Transactions
A transaction is the actual unit of work being performed, while ACID properties are the guarantees that make that unit of work reliable.
Think of it this way: the transaction is the "what" (debit and credit two accounts), and ACID is the "how" (the four promises that make sure it happens safely).
For a deeper look at transaction states like Active, Committed, and Aborted, see Transactions in DBMS.
Quick Revision Cheat Sheet
One final scan before your mock test.
| Property | Meaning | Exam Keyword to Watch For |
|---|---|---|
| Atomicity | All steps succeed, or none do | "Partial transaction," "some steps fail" |
| Consistency | Database stays valid and follows its rules | "Valid state," "integrity," "constraints preserved" |
| Isolation | Transactions running together don't interfere | "Concurrent," "dirty read," "phantom read" |
| Durability | Committed changes are never lost | "COMMIT," "system crash," "power failure" |
🎯 Revision Checklist
Tick the concepts you're confident about before attempting the mock test.
Practice Topic-wise Mock Tests
Revise one topic at a time, then reinforce it immediately with a matching test.
Ready to Test Your IT Professional Knowledge?
Access subject-wise free mock tests for every IT domain topic — DBMS, Computer Networks, OS, Software Engineering, and DSA — with detailed explanations and AI-powered question generation.
What to Study Next
Continue your DBMS revision with these related articles.