What does ACID mean, and why does each property matter?
Quick Answer
**Atomicity** — a transaction's operations all succeed or all roll back, never partially apply. **Consistency** — a transaction moves the database from one valid state to another, never violating constraints. **Isolation** — concurrent transactions don't see each other's uncommitted intermediate state. **Durability** — once committed, data survives crashes/power loss. Together they let application code treat a multi-statement operation as a single, safe unit even under concurrency and failure.
Detailed Answer
ACID describes the guarantees a database transaction makes, letting you reason about a group of statements as a single, safe operation even in the presence of concurrent access and crashes.
Atomicity — all or nothing
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1; -- debit
UPDATE accounts SET balance = balance + 100 WHERE id = 2; -- credit
COMMIT;
If the second UPDATE fails (constraint violation, crash, connection drop) before COMMIT, the first UPDATE must also be undone — you should never end up with money debited from account 1 but not credited to account 2. Without atomicity, every multi-step write needs manual, error-prone compensating logic in application code.
Consistency — valid state to valid state
The transaction must leave the database satisfying all defined constraints (NOT NULL, CHECK, foreign keys, unique constraints) — if a CHECK (balance >= 0) constraint exists, no committed transaction can ever leave a negative balance, even mid-transaction states are allowed to (temporarily) violate it as long as they don't at commit time. Note: this is the least precisely defined of the four letters, and is partly just "atomicity + isolation + valid constraints together imply the DB stays consistent," rather than a fully independent mechanism.
Isolation — concurrent transactions don't interfere
-- Transaction A -- Transaction B
BEGIN;
UPDATE accounts SET balance = 500
WHERE id = 1;
BEGIN;
SELECT balance FROM accounts
WHERE id = 1; -- should NOT see 500 yet
-- (depending on isolation level)
COMMIT;
Isolation determines exactly what "shouldn't see yet" means in practice — this is where the four standard isolation levels (Read Uncommitted, Read Committed, Repeatable Read, Serializable) come in, each allowing or preventing different classes of interference (see that question).
Durability — survives a crash
COMMIT;
-- Power fails immediately after this returns successfully to the client.
-- On restart, the committed data MUST still be there.
Achieved via a write-ahead log (WAL) — the engine writes a durable log record of the change before acknowledging the commit, so it can replay the log to recover committed-but-not-yet-flushed-to-disk data after a crash (see the WAL question in the scaling/HA topic).
Why this matters for interviews
ACID isn't just trivia — it's the contract that lets you write BEGIN ... COMMIT blocks around multi-step business logic (like a funds transfer) and trust the database to handle failure and concurrency correctly, instead of hand-rolling that safety in application code. Being able to explain a concrete failure each property prevents (not just recite the acronym) is what distinguishes a strong answer.