Introduction Your program keeps opening transactions.
A signup writes a new user row.
A checkout debits one account and credits another.
A form submission updates three related tables at once.
You wrap it all in BEGIN and COMMIT and move on, trusting that the database will handle whatever happens in between.
Most of the time it does.
But what is it actually promising you when it handles that?
And what does it have to do behind the scenes to keep that promise?
Say a user transfers ₹1,000 from Account A to Account B.
The application runs two updates: subtract 1,000 from A, add 1,000 to B.
Now say the server crashes right after the first update runs but before the second one does.
Account A: -₹1,000 Account B: +₹0 That money didn't move.
It vanished.
No error message fixes that, and no user accepts "the server restarted" as an explanation for their missing balance.
This is the exact problem a set of guarantees called ACID was built to solve.
Most developers can recite the acronym, Atomicity, Consistency, Isolation, Durability, without being able to explain what any of the four words actually promise, or what the database has to do internally to keep those promises.
This article tries to fix that. --
1.
What Is a Transaction?
Before ACID makes sense, you need to understand what a transaction actually is.
A transaction is a group of one or more database operations treated as a single logical unit of work.
Either the whole group succeeds, or none of it does.
The bank transfer above is a textbook transaction: two updates that only make sense together.
In SQL, a transaction usually looks like this: BEGIN tells the database "everything from here on is one unit." COMMIT tells it "we're done, make it permanent." If something goes wrong in between, a constraint violation, a crash, the application deciding to cancel, the database can issue a ROLLBACK instead, undoing any changes the transaction made so far.
From the outside, it's as if the transaction never ran at all.
That single idea, a transaction either fully happens or fully doesn't, is the seed ACID grows out of. --
2.
Atomicity: All or Nothing Atomicity is the guarantee that a transaction's operations are treated as one indivisible unit.
If any part fails, the transaction's own effects are rolled back, so it does not leave behind a partial result.
This is what prevents the "money disappeared" scenario.
If the second UPDATE never runs, the database rolls back the first one too, so Account A never actually loses its money in any state a user or another transaction can observe.
Worth being precise about what atomicity does and doesn't cover.
It guarantees the transaction as a whole is all-or-nothing.
It doesn't mean every individual statement behaves identically across every database engine, and it says nothing about what other concurrent transactions can see while this one is running.
That's a different guarantee, and it's the interesting one. --
3.
Consistency: Preserving the Rules of the Database This is the word people get wrong most often, usually by simplifying it down to "the database has correct data." That's too vague to be useful.
In ACID, consistency means a successful transaction takes the database from one valid state to another valid state, where "valid" is defined by the constraints and rules you've told the database to enforce.
Consistency isn't something the database magically guesses.
You define it: A CHECK constraint that says a balance can't go negative A foreign key that requires an order's customer_id to reference an actual row in the customers table A UNIQUE constraint that says two users can't share the same email address If a transaction would violate any of these, the database refuses to commit it and rolls it back instead.
Consistency is really the database enforcing your rules, not the database independently deciding what's correct.
It's also worth separating ACID consistency from a completely different idea that shares the same word: consistency in distribu