ACID Properties

ACID — Atomicity, Consistency, Isolation, Durability — is the set of guarantees a database makes about how transactions behave. PostgreSQL has a long-standing reputation as one of the most reliably ACID-compliant open-source databases, which is a big part of why it's trusted for financial systems, inventory, and other data where correctness genuinely can't be compromised.

The four properties

Property	Guarantee	How PostgreSQL implements it
Atomicity	A transaction's statements either all take effect, or none do	Uncommitted changes are tracked and discarded on `ROLLBACK` or a failure; nothing partial is ever left behind
Consistency	A transaction can only move the database from one valid state to another — constraints, foreign keys, and rules are never violated	Enforced via constraints (`CHECK`, `NOT NULL`, `UNIQUE`, foreign keys) that are checked before any transaction is allowed to commit
Isolation	Concurrent transactions don't see each other's uncommitted, in-progress changes	Implemented through MVCC (Multi-Version Concurrency Control) and configurable isolation levels
Durability	Once a transaction is committed, it survives a crash, power loss, or restart	Achieved via WAL (Write-Ahead Logging) — changes are flushed to a durable log before the commit is acknowledged

Why ACID matters

Without these guarantees, ordinary operations become dangerous. Without atomicity, a crash mid-transfer could deduct money from one account without ever crediting another. Without consistency, bad data could silently violate the rules your application depends on. Without isolation, one transaction could read another's half-finished work and act on numbers that were never actually true. Without durability, a "successful" commit could simply vanish the moment the server restarts. ACID is what lets application code assume the database will behave sanely, rather than having to defensively work around it.

Note

Durability specifically rests on WAL — before PostgreSQL modifies the actual data files on disk, it first writes a record of the change to a sequential write-ahead log. If the server crashes before the data files are fully updated, PostgreSQL replays the WAL on restart to reconstruct any committed changes that hadn't yet been written back. WAL is also the foundation for PostgreSQL's replication and point-in-time recovery features, covered elsewhere in this series.

Atomicity — all-or-nothing transactions.
Consistency — constraints and rules are never violated.
Isolation — concurrent transactions don't see each other's uncommitted work.
Durability — committed data survives a crash, backed by Write-Ahead Logging (WAL).
PostgreSQL's strong ACID compliance is one of its core, long-standing strengths.