ACID Properties: Why Your Database Doesn't Lose Your Data
Ever wondered how a bank transfer doesn't mess up even if your app crashes mid-way? Or how an online order doesn't get half-placed? That's ACID doing its job quietly in the background.
ACID is a set of four properties that every reliable database transaction follows. Let's break each one down.
What's a Transaction First?
Before ACID, we need to understand what a transaction is. A transaction is a group of operations that should either all succeed or all fail together. Think of it like: "Transfer ₹500 from Account A to Account B" — that's two steps (debit A, credit B), but they're one transaction.
A — Atomicity
"All or nothing."
If a transaction has 5 steps, either all 5 complete or none of them do. There's no in-between. If anything fails halfway through, the database rolls back to the state before the transaction started — like it never happened.
Example: You're booking a flight. The system reserves your seat AND charges your card. If the payment fails, the seat reservation also gets cancelled. You don't end up with a reserved seat and no charge — that would be chaos.
C — Consistency
"The database always stays valid."
Before and after a transaction, the database must be in a valid state according to all defined rules and constraints. If a rule says "account balance can't go below zero", no transaction can break that rule.
Example: If Account A has ₹200 and you try to transfer ₹500 — consistency says no. The transaction won't go through because it would leave the database in an invalid state.
I — Isolation
"Transactions don't step on each other."
When multiple transactions are running at the same time, they shouldn't interfere with each other. Each transaction should feel like it's the only one running, even if there are hundreds happening in parallel.
Example: Two people booking the last seat on a flight simultaneously. Isolation ensures only one of them gets it — the other sees an updated state and gets rejected. Without isolation, you'd have two people "holding" the same seat.
Isolation is one of the trickier ones to implement at scale. Databases use techniques like locking and MVCC (Multi-Version Concurrency Control) to handle this without killing performance.
D — Durability
"Once committed, it stays."
After a transaction is successfully committed, the data is permanent — even if the server crashes right after. The database uses techniques like write-ahead logging (WAL) to make sure committed data survives failures.
Example: You receive a "Payment Successful" confirmation. Even if the server dies one second later, your payment is saved. It won't mysteriously disappear when the server restarts.
Quick Summary
| Property | What it guarantees |
|---|---|
| Atomicity | All steps succeed, or none do |
| Consistency | Database rules are never broken |
| Isolation | Concurrent transactions don't interfere |
| Durability | Committed data survives crashes |
Why Does This Matter?
Without ACID, databases would be unreliable for anything serious — banking, orders, bookings, healthcare records. These four properties are what make us trust that the data we write actually stays the way we left it.
Most relational databases like PostgreSQL, MySQL, and SQL Server are ACID-compliant by default. NoSQL databases sometimes trade some of these guarantees for speed and scale — but that's a story for another day.
ACID isn't just theory — it's the foundation that makes production databases trustworthy. Understanding it helps you make better decisions when choosing or configuring your database.