ACID describes four properties that database systems use to keep transactions safe and reliable. A transaction is a group of operations (e.g. “deduct money from A and add it to B”) that the database treats as one unit: either everything succeeds or everything is undone.
A – Atomicity
“All or nothing.” Either every step in the transaction completes, or none of them do. If something fails in the middle (e.g. a crash or an error), the database rolls back any changes from that transaction, so you never see half-done updates (like money taken from A but not yet added to B).
C – Consistency
Before and after the transaction, the database stays in a valid state according to its rules (constraints, keys, etc.). So if your rules say “account balance cannot be negative,” a transaction that would make a balance negative is either rejected or rolled back. Consistency is what you get when atomicity and the other properties work together with your business rules.
I – Isolation
Concurrent transactions don’t step on each other. While one transaction is running, others either wait or see a consistent view of the data, so you don’t get messy results like “dirty reads” (reading uncommitted data) or “lost updates” (one transaction overwriting another’s change). The database isolates each transaction as if it were running alone, to whatever level the system guarantees.
D – Durability
Once a transaction is committed, its changes are permanent. Even if the database or server crashes right after, when the system comes back up the committed data is still there. This is usually achieved by writing to disk (or a durable log) before saying “commit successful.”
Together, ACID gives you predictable, safe behavior when many users or processes change data at the same time.