What does ACID mean, and why does each property matter?

ACID describes the guarantees a database transaction makes. It lets 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 — 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. It's 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.