# ACID ACID is the four-property contract that database transactions are expected to satisfy. The acronym stands for Atomicity, Consistency, Isolation, and Durability. Coined by Andreas Reuter and Theo Härder in 1983, it remains the dominant mental model for reasoning about correctness in [[Relational Databases (RDBMS)|relational]] and increasingly non-relational databases. ## The Four Properties ### Atomicity A transaction is all-or-nothing. Either every operation in it succeeds and is committed, or none of them takes effect. Partial application is impossible; on failure the database rolls back to the pre-transaction state. See [[Atomicity]] for the broader concept. ### Consistency A transaction moves the database from one valid state to another. "Valid" here means satisfying all declared invariants: foreign keys, check constraints, uniqueness, triggers. Note that *application*-level consistency (business rules) is the developer's responsibility; the database guarantees only what its schema declares. ### Isolation Concurrent transactions appear as if they ran one after the other, even when they actually overlap. The strongest isolation level is serializable; weaker levels (read committed, repeatable read, snapshot) trade correctness for throughput and expose phenomena like dirty reads, non-repeatable reads, and phantom reads. ### Durability Once a transaction is committed, its effects survive crashes, power failures, and restarts. In practice this means the change has been written to non-volatile storage; usually via [[Write-Ahead Logging (WAL)]] and an `fsync` before acknowledging the commit. ## Why It Matters ACID is the contract that lets developers think about state changes as if they were single, instantaneous operations on a single-threaded machine. Without it, every read becomes "what does the database currently look like, accounting for every concurrent writer and possible crash?". That is an unmanageable cognitive load. ## ACID vs BASE The NoSQL wave of the late 2000s popularized BASE (Basically Available, Soft state, Eventually consistent) as an explicit *rejection* of ACID for horizontal-scale systems. The trade-off is real (CAP theorem), but the pendulum has swung back: most modern distributed databases (Spanner, CockroachDB, TiDB, FoundationDB) target ACID semantics again, having found other ways to scale. ## Common Misunderstandings - **"My database is ACID"** does not mean your *application* is consistent. Schema constraints catch only what you've declared. - **Isolation has levels.** Many systems advertise ACID while defaulting to read committed, which permits anomalies a strict reading of "I" would forbid. - **Durability is configurable.** Many engines let you trade durability for speed (e.g., `synchronous_commit=off` in PostgreSQL). "ACID" is a property of the configuration, not of the engine. ## References - Original paper (Reuter & Härder, 1983): "Principles of Transaction-Oriented Database Recovery" - https://en.wikipedia.org/wiki/ACID ## Related - [[Atomicity]] - [[Write-Ahead Logging (WAL)]] - [[Database]] - [[Database Management Systems (DBMS)]] - [[Relational Databases (RDBMS)]] - [[SQLite]] - [[PostgreSQL]]