The Four Guarantees of Database Transactions
ACID is an acronym for the four properties that define a reliable database transaction: Atomicity, Consistency, Isolation, and Durability. Together, they form a contract between the database and the application developer: if your operations are wrapped in a transaction, the database guarantees these four properties hold, no matter what — including crashes, hardware failures, and concurrent access by other users.
Atomicity
A transaction is all or nothing. Either every operation in the transaction completes successfully, or none of them take effect. If a bank transfer involves debiting Account A and crediting Account B, atomicity guarantees that you will never end up in a state where A is debited but B is not credited. If the system crashes midway through, the entire transaction is rolled back as if it never happened. In PostgreSQL, atomicity is implemented via the write-ahead log (WAL) — uncommitted changes can be undone using the undo information in log records.
Consistency
The database moves from one valid state to another. "Valid" means all constraints are satisfied: primary keys, foreign keys, CHECK constraints, NOT NULL constraints, and triggers. If a transaction would violate any constraint, the entire transaction is rejected. For example, if a foreign key requires that every order references a valid customer, an INSERT into orders with a nonexistent customer_id is rejected. Consistency is enforced by the database engine at commit time — constraints are checked, and if any fail, the transaction aborts.
Isolation
Concurrent transactions do not interfere with each other. Each transaction executes as if it were the only one running. Without isolation, two concurrent transfers from the same account could both read the same balance, both debit it, and the account loses only one debit instead of two (a lost update). Isolation levels (Read Uncommitted, Read Committed, Repeatable Read, Serializable) control the trade-off between strictness and performance. Stronger isolation prevents more anomalies but reduces concurrency.
Durability
Once a transaction is committed, its effects survive any subsequent failure — power outage, disk crash, or operating system panic. Durability is implemented by ensuring the WAL records for the transaction are flushed to stable storage (disk or battery-backed write cache) before the COMMIT returns to the client. Even if the database crashes immediately after the commit, the recovery process replays the WAL and restores the committed data.
ACID as a Contract
ACID is not just a set of internal mechanisms — it is a contract with the application developer. You write application code under the assumption that transactions are atomic, consistent, isolated, and durable. Without this contract, every application would need to implement its own crash recovery, constraint checking, and concurrency control — enormously complex and error-prone.
BASE: The Alternative in Distributed Systems
Distributed systems (NoSQL databases, microservices) often relax ACID in favor of BASE: Basically Available (the system responds even during failures), Soft state (state may change over time without input, due to eventual consistency), Eventually consistent (given enough time without updates, all replicas converge). BASE trades strong consistency for availability and partition tolerance, as described by the CAP theorem: in a distributed system, you can only guarantee two of three: Consistency, Availability, Partition tolerance.
ACID in a Bank Transfer
Consider a bank transfer of $500 from Account A (balance $1000) to Account B (balance $300):
BEGIN;
UPDATE accounts SET balance = balance - 500 WHERE id = 'A';
UPDATE accounts SET balance = balance + 500 WHERE id = 'B';
COMMIT;
Atomicity in action:
- If the system crashes after the first UPDATE but before COMMIT, the WAL has no COMMIT record. Recovery rolls back the debit from A. Both accounts remain unchanged.
- If COMMIT succeeds, both updates are permanent.
Consistency in action:
- A CHECK constraint
balance >= 0prevents overdrafts. If Account A had only $300, the first UPDATE would violate the constraint and the entire transaction would abort.
Isolation in action:
- Another transaction reading Account A's balance during this transfer sees either $1000 (before) or $500 (after), never an intermediate state. Under Read Committed isolation, the other transaction sees $1000 until the transfer commits.
Durability in action:
- The COMMIT call does not return to the client until the WAL records are flushed to disk. If the server loses power 1 millisecond after COMMIT returns, the transfer is guaranteed to survive.
ACID violation example (no transactions):
// Without a transaction:
db.execute("UPDATE accounts SET balance = balance - 500 WHERE id = 'A'");
// Server crashes HERE
db.execute("UPDATE accounts SET balance = balance + 500 WHERE id = 'B'");
Account A is debited but B is never credited. $500 disappears. This is exactly what atomicity prevents.
BASE example (eventual consistency): In a distributed system with replicas, after committing the transfer on the primary, replicas may take milliseconds to seconds to reflect the change. During that window, reading from a replica might show the old balance — this is "eventually consistent." For a bank transfer this is typically unacceptable, which is why financial systems use ACID databases.