ACID properties

ACID is Atomicity, Consistency, Isolation, Durability. It is the contract Postgres signs with you when you wrap statements in BEGIN ... COMMIT. Break the contract and money goes missing.

The four letters, fast

• Atomicity: all or nothing. If any statement in the transaction fails, every statement rolls back. There is no half-applied transfer.
• Consistency: the transaction takes the database from one valid state to another. Constraints, foreign keys, triggers, all hold at commit time. This is the weakest property because it is mostly your job, not the DB's.
• Isolation: concurrent transactions do not see each other's dirty work. The strength of isolation depends on the level you pick (Read Committed, Repeatable Read, Serializable).
• Durability: once COMMIT returns, the data survives a crash. The write-ahead log (WAL) is fsynced to disk before the client sees success.

Why it matters

Without atomicity, your bank app debits $100 from Alice and crashes before crediting Bob. The money is gone. Without durability, you tell Bob "transfer complete" and the DB crashes 200ms later and the row is gone.

The interview line

"ACID is the guarantee that a transaction either fully happens or fully does not, even across crashes and concurrent writers. Postgres gets durability from the WAL and fsync, isolation from MVCC plus row locks, atomicity from the same WAL replay logic, and consistency by enforcing constraints at commit time."

Common confusion

The "C" in ACID is not the "C" in CAP. ACID consistency means "constraints hold." CAP consistency means "all nodes see the same data." Different problems, same letter.

When you do not want full ACID

Analytics warehouses (Snowflake, BigQuery) relax isolation for throughput. Caches (Redis) skip durability for speed. Event logs (Kafka) skip atomicity across partitions. ACID is a cost. Pay it where correctness matters, skip it where it does not.