@sargonpiraev

ACID

Created 3 min readseed · 1/5#database

ACID is a set of guarantees a database provides around transactions. It explains what the database promises when multiple reads and writes are grouped into one unit of work.

Atomicity

Atomicity means a transaction is all-or-nothing. Either every operation inside the transaction commits, or the database rolls the whole thing back.

Example: if an order creates a payment row, decrements inventory, and writes an audit event, atomicity prevents only two of those three changes from surviving.

Consistency

Consistency means a transaction moves the database from one valid state to another valid state.

The database keeps its rules intact: foreign keys still point to existing rows, unique constraints stay unique, checks still pass, and required invariants are not broken by a committed transaction.

Isolation

Isolation controls what concurrent transactions can see from each other.

Without isolation, one transaction could read another transaction's unfinished work, make a decision from it, and then be wrong if that other transaction rolls back.

Isolation levels

Isolation is not just on/off. Databases usually expose levels with different tradeoffs:

  • Read Uncommitted — a transaction may see uncommitted changes from another transaction. This allows dirty reads and is rarely what application code wants.
  • Read Committed — a transaction only sees data that was committed before each statement starts. It prevents dirty reads, but the same query can return different results if repeated later in the same transaction.
  • Repeatable Read — a transaction gets a stable view of rows it has already read. It prevents many surprising changes inside a transaction, but different databases define the edge cases differently.
  • Serializable — the strongest common level. The database behaves as if transactions ran one at a time, even when it executes them concurrently. This prevents the most anomalies, but can increase conflicts and retries.

Common anomalies

  • Dirty read — reading data written by another transaction before it commits.
  • Non-repeatable read — reading the same row twice and getting different values because another transaction committed between reads.
  • Phantom read — repeating a query and seeing new matching rows appear because another transaction inserted them.

The practical tradeoff: stronger isolation gives simpler reasoning, but can cost throughput or force the application to retry failed transactions.

Durability

Durability means that once the database confirms a transaction as committed, the result should survive crashes.

In practice, databases usually achieve this through a durability mechanism like a write-ahead log: record the change safely first, then apply it to the main data files.

Mental model

ACID is what makes a database more than a smart file. You pay some latency and complexity for the guarantee that important changes happen completely, consistently, and durably.

For money, orders, identity, permissions, and other business-critical state, those guarantees are usually mandatory.