ACID Properties

Also Known As

TL;DR

Explanation

ACID ensures reliable transaction processing: Atomicity — a transaction either fully succeeds or fully rolls back (no partial writes); Consistency — the database moves from one valid state to another, enforcing constraints; Isolation — concurrent transactions don't see each other's intermediate state (controlled by isolation levels: Read Uncommitted, Read Committed, Repeatable Read, Serializable); Durability — committed transactions survive crashes (via write-ahead logging). In PHP, manage transactions explicitly with PDO::beginTransaction(), commit(), and rollBack(), especially when multiple related writes must succeed together.

Diagram

flowchart TD
    subgraph ACID
        A[Atomicity<br/>all or nothing<br/>no partial writes]
        C[Consistency<br/>business rules<br/>always maintained]
        I[Isolation<br/>concurrent transactions<br/>don't interfere]
        D[Durability<br/>committed data<br/>survives crashes]
    end
    TRANS[Database Transaction] --> A & C & I & D
    FAIL[Power failure<br/>during write] -->|redo log| D
    CONC[Concurrent writes] -->|locks + MVCC| I
style A fill:#238636,color:#fff
style C fill:#238636,color:#fff
style I fill:#1f6feb,color:#fff
style D fill:#6e40c9,color:#fff

Common Misconception

Why It Matters

Common Mistakes

• Assuming NoSQL databases are ACID — most sacrifice isolation or durability for performance.
• Not wrapping multi-step operations in a transaction — a crash between steps leaves data inconsistent.
• Using READ UNCOMMITTED isolation — allows dirty reads of data that may be rolled back.
• Relying on application-level locking instead of database transactions for concurrency.

Avoid When

• You need horizontal scalability across distributed nodes — full ACID across shards requires coordination overhead.
• The workload tolerates eventual consistency — sacrificing isolation for availability (BASE model) may be correct.
• Using NoSQL stores that offer only document-level atomicity — do not assume full ACID without verifying.

When To Use

• Financial transactions, inventory management, or any domain where partial writes are catastrophic.
• Any operation touching multiple rows or tables that must succeed or fail atomically.
• Concurrent workloads where isolation prevents dirty reads and phantom reads.
• Systems where durability guarantees are required — data must survive a crash without loss.

Code Examples

// Two separate queries without a transaction — partial failure leaves inconsistent state
$pdo->exec("UPDATE accounts SET balance = balance - 100 WHERE id = 1");
$pdo->exec("UPDATE accounts SET balance = balance + 100 WHERE id = 2");

try {
  $pdo->beginTransaction();
  $pdo->exec("UPDATE accounts SET balance = balance - 100 WHERE id = 1");
  $pdo->exec("UPDATE accounts SET balance = balance + 100 WHERE id = 2");
  $pdo->commit();
} catch (Exception $e) {
  $pdo->rollBack(); throw $e;
}

References

• ↗ https://en.wikipedia.org/wiki/ACID
• ↗ https://www.php.net/manual/en/pdo.transactions.php

Tags

Related Terms