# ACID Properties guaranteeing reliable database transaction processing. ## The Four Properties - **Atomicity** — all-or-nothing. If any part fails, the entire transaction rolls back. Example: in a bank transfer, both debit and credit must succeed or neither happens. - **Consistency** — a transaction brings the database from one valid state to another, enforcing all constraints, cascades, and triggers. - **Isolation** — concurrent transactions execute as if sequential. Isolation levels (Read Uncommitted → Read Committed → Repeatable Read → Serializable) trade strictness for performance. - **Durability** — once committed, data persists even through crashes. Typically via write-ahead logging (WAL). ## In Practice - **Relational databases** (PostgreSQL, MySQL, Oracle) are ACID-compliant by default - **NoSQL databases** often relax ACID for performance/scalability (see BASE: Basically Available, Soft state, Eventually consistent) - **Distributed transactions** use protocols like two-phase commit (2PC) to maintain ACID across nodes, at the cost of latency --- See also: [[Database Transaction Schedule]], [[Write-Write Conflict]]