ACID

ACID is an acronym for four properties that a database management system guarantees for transactions. A transaction is a unit of work — such as transferring money between accounts — that must succeed or fail as a whole. ACID makes such operations trustworthy in the face of crashes, power loss, and concurrent users.

How It Works

• Atomicity: A transaction is all-or-nothing. If any step fails, the entire transaction is rolled back and the database is left unchanged.
• Consistency: A transaction moves the database from one valid state to another, enforcing constraints, cascades, and triggers. Invalid states are rejected.
• Isolation: Concurrent transactions do not interfere with one another. The result is as if they ran one after another. Databases offer isolation levels (read committed, repeatable read, serializable) that trade strictness for performance.
• Durability: Once a transaction commits, its effects survive crashes. This is typically achieved with write-ahead logs flushed to durable storage.

Relational databases such as PostgreSQL, MySQL (InnoDB), Oracle, and SQL Server implement ACID natively. Many modern distributed databases (CockroachDB, Google Spanner) provide ACID across nodes.

Why It Matters

ACID is the foundation of correctness for systems where data integrity is non-negotiable: banking, inventory, ordering, and ledgers. Without it, partial updates and race conditions can corrupt data silently. The main trade-off is performance and scalability at extreme scale, which is why some distributed systems relax guarantees in favor of the BASE model and eventual consistency.

Related Terms

Contrast ACID with the BASE model used by many NoSQL systems, and see the CAP theorem for the limits on consistency in distributed databases.