Skip to content
Devgo

ACID

A set of guarantees for transactions: Atomicity, Consistency, Isolation, Durability. ACID transactions appear all-or-nothing, keep data valid, don't interfere, and survive crashes. The gold standard for correctness; relational DBs provide it.

When to use
  • Financial and business transactions needing correctness.
  • Any multi-step write that must be all-or-nothing.
When not to
  • High-throughput workloads tolerating eventual consistency.
  • Globally distributed writes where 2PC latency is unacceptable.

Definition

Atomicity: all-or-nothing. Consistency: transactions move the DB from one valid state to another. Isolation: concurrent transactions appear sequential. Durability: committed writes survive crashes. Relational DBs provide ACID via , locking, and WAL.

Why it exists

Real operations span multiple rows/tables and must not leave partial updates on failure, nor corrupt data under concurrency. ACID gives the strong guarantees financial and business logic require.

How it works

Atomicity via undo/rollback . Durability via WAL fsync. Isolation via ( isolation) or locks; serializable is the strongest. Consistency is enforced by constraints. Distributed ACID needs 2PC or a consensus log, which is costly.

Scaling limits

Strong isolation (serializable) reduces concurrency. Distributed ACID (2PC) is slow and fragile. Long transactions hold locks and cause contention. Most trades ACID for scale.

Cost shape

Locking and WAL overhead per transaction. Blow-ups: long transactions, lock contention, and distributed transactions across shards.

Alternatives

  • BASE / eventual consistency — Scales better, but no immediate consistency.
  • Saga — Long transactions as a sequence with compensations, not atomic.

Failure modes

  • Long transactions causing lock contention.
  • Deadlocks.
  • Distributed 2PC blocking on failures.

, , , ,