What does ACID mean in databases?
Take a moment.
Say your answer out loud or write it down first — retrieval is what makes it stick. Reveal when you're ready.
Short answer
ACID is the contract for reliable transactions: Atomicity (all-or-nothing), Consistency (rules never violated), Isolation (concurrent transactions don't see each other's partial work), Durability (committed data survives crashes). It is why a payment and its ledger entry can never half-exist.
Detailed explanation
A transaction groups statements into one unit the database executes reliably. Atomicity means the group commits entirely or rolls back entirely — a transfer debiting Alice and crediting Bob never leaves money debited but uncredited; on any error the engine undoes the partial work. Consistency means each transaction moves the database from one valid state to another: constraints, foreign keys, and checks hold before and after; a transaction that would violate them aborts instead of corrupting data. Isolation means concurrent transactions behave as if serialized — one transaction's uncommitted writes are invisible to others (the exact strength is tuned by the isolation level). Durability means once COMMIT returns, the data survives power loss and crashes, implemented with a write-ahead log flushed to disk before acknowledging. Together they let application code treat a multi-statement update as a single trustworthy step. Classic use: order placement decrementing stock, charging payment, and creating the shipment row in one transaction — any failure rolls everything back and the customer can safely retry.
Example
-- Money transfer: both legs or neither
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 'alice';
UPDATE accounts SET balance = balance + 100 WHERE id = 'bob';
COMMIT; -- crash before this line? Engine rolls back; no money is lost or created
-- On error, abort explicitly:
-- BEGIN; ... ; ROLLBACK;Interview tip
Expand each letter with a one-line money-transfer illustration. The detail that impresses is naming the write-ahead log as the durability mechanism.
Common mistakes
- Confusing Consistency (constraint preservation) with general 'correctness'.
- Assuming durability without knowing the write-ahead log exists.