ACID is the acronym for four properties that define how a database system guarantees reliable transaction processing: Atomicity, Consistency, Isolation, and Durability. A transaction is any sequence of database operations — like inserting a row, updating a balance, or deleting a record — that your application treats as a single logical unit of work. When a database claims to be ACID-compliant, it promises that every transaction runs as if it were the only operation happening at that moment, and that the database will never be left in a corrupted state — even if the power fails mid-operation, the server crashes, or two users submit conflicting changes simultaneously.
You interact with ACID guarantees every time you transfer money between bank accounts, place an online order, or update a shared inventory count. Without these four rules, a single failed step in any of those operations could leave your data permanently wrong, with no way to recover. This guide walks through each property in sequence, what failure mode it prevents, and how you can reason about them when designing your own database schemas and queries.
Step 1: Atomicity — All or Nothing
Atomicity means a transaction must complete in full or not at all. There is no partial state, no half-written row, no update that applies to one column but fails on the next. If any single operation inside the transaction fails, the entire transaction rolls back, and the database returns to exactly the state it was in before the transaction started.
Consider transferring $100 from Account A to Account B. That transfer requires two operations: subtract $100 from A, then add $100 to B. Without atomicity, a crash between those two steps leaves $100 missing from the system — deducted from A but never deposited into B. Atomicity ensures both operations commit together or neither does. If the deposit step fails, the deduction is undone automatically.
Your mental model: a transaction is a single, indivisible unit, much like a single row in a ledger — it either appears in full or does not appear at all. In practice, you mark transaction boundaries with BEGIN and COMMIT (or ROLLBACK), and the database engine enforces atomicity for you. You never need to write cleanup code for partial operations — that is the database’s job, guaranteed by the engine.
The failure mode atomicity prevents: lost or duplicated data from interrupted operations. A crash mid-transaction, an explicit error, or a constraint violation during any step — all of these trigger a full rollback automatically.
Step 2: Consistency — The Database Never Violates Its Own Rules
Consistency, in the ACID sense, means a transaction cannot leave the database in a state that violates any defined rules — constraints, triggers, cascading rules, unique keys, foreign key references, or any application-level invariant you’ve declared on your schema. Whatever set of valid states your database defines, every transaction must move the database from one valid state to another valid state.
A practical example: a bank has a rule that account balances cannot go negative. A transaction that attempts to withdraw $200 from a $150 balance violates that rule. Consistency guarantees the database rejects the transaction — it does not allow the withdrawal to partially execute and then discover the violation halfway through. The transaction fails as a whole, and the database remains in a valid state.
This property works hand in hand with atomicity. Atomicity ensures no partial execution; consistency ensures that even a fully executed transaction cannot break your database’s own rules. When you define a CHECK constraint, a foreign key, or a UNIQUE index, you are asking the database to enforce consistency on your behalf. The failure mode consistency prevents: data that silently contradicts your schema — duplicate records, orphaned rows, balances below zero, or dates that violate your own business logic.
Step 3: Isolation — Transactions Do Not Interfere With Each Other
Isolation controls how concurrently running transactions interact with one another. When two users update the same row at the same time, or one reads while another writes, isolation defines what each one sees and whether their operations interfere. Without isolation, two concurrent transactions could read the same value, compute different updates based on that read, and both write — silently overwriting one another’s changes.
Your mental model: each transaction behaves as if it runs alone on the database, no matter how many other transactions are executing at the same moment. Isolation is adjustable, however — databases let you trade strictness for performance through isolation levels like READ COMMITTED, REPEATABLE READ, and SERIALIZABLE. Defaults vary by engine. PostgreSQL defaults to READ COMMITTED. MySQL’s InnoDB defaults to REPEATABLE READ. SERIALIZABLE provides the strongest guarantee — transactions behave as if executed one after another in some order — at the cost of reduced concurrency.
The failure modes isolation prevents include dirty reads (reading uncommitted data), non-repeatable reads (the same query returning different results within one transaction because another transaction committed in between), and lost updates (two transactions overwriting each other’s writes). Choosing an isolation level is your deliberate trade-off between data accuracy and concurrent throughput — and understanding your application’s tolerance for each anomaly type is the deciding factor.
Step 4: Durability — Committed Data Survives Any Failure
Durability guarantees that once a transaction commits, its changes are permanent — even if the database crashes, the power fails, or the server restarts moments later. Committed data is written to durable, non-volatile storage — typically a transaction log on disk — before the database confirms the commit to your application. A crash after that point recovers the committed state from the log, so your data is not lost or corrupted.
Consider an ecommerce order: your customer pays, the order transaction commits, and the database confirms success. If the server loses power five seconds later, durability ensures that when the database restarts, that order still exists — it was already written to the transaction log before the confirmation was sent. Without durability, the database might confirm your commit, then lose the data in a crash — a failure mode that silently betrays the application’s promises.
In practice, durability depends on storage hardware (solid-state drives versus spinning disks), filesystem settings, and database configuration flags like synchronous_commit in PostgreSQL. Weaker durability settings improve write performance by acknowledging commits earlier, at the risk of losing recent transactions in a crash. The question to ask yourself: for this transaction, how much write latency am I willing to trade for certainty of survival?
The Four Properties as a Sequence of Guarantees
When you write a transaction, these four properties stack together to form a complete safety contract:
- Atomicity — if any step fails, the entire transaction rolls back.
- Consistency — a successful transaction cannot violate database rules.
- Isolation — concurrent transactions do not corrupt one another.
- Durability — a committed transaction survives crashes.
Each property addresses a distinct failure mode, and all four are required for a database to be trustworthy under real-world conditions — where crashes, concurrency, and user errors are not rare edge cases but the normal operating environment.
What ACID Does Not Guarantee
ACID does not guarantee application-level correctness. A transaction that performs a logically wrong business operation — transferring $100 from the wrong account, or computing a discount incorrectly — will commit happily if it does not violate database constraints. ACID protects the structure and integrity of your data, not the semantic accuracy of your business logic.
ACID also does not guarantee performance. The mechanisms that provide these properties — logs, locks, isolation tracking — add measurable write overhead and reduce concurrent throughput compared to relaxed guarantees. Distributed systems often sacrifice some ACID guarantees for availability and performance, which is why you hear about eventual consistency in systems that cannot provide strong ACID semantics across multiple servers.
Choosing ACID-Compliant Storage
When you select a database engine, the ACID question matters. Traditional relational databases — PostgreSQL, MySQL with InnoDB, SQL Server, Oracle — enforce all four properties by default. Some NoSQL systems provide ACID only for single-document transactions, while others lack full ACID guarantees entirely in favor of speed and horizontal scaling.
The practical rule: if your application cannot tolerate lost or corrupted data — financial transactions, inventory management, user accounts, order processing — choose a database with mature ACID enforcement, and let the database engine handle safety rather than writing manual compensating logic. If your workload tolerates eventual consistency and your primary constraint is throughput at massive scale, a non-ACID system may be the right trade-off — but only when you have explicitly measured and accepted the failure modes that come with it.
What specific operation are you concerned about — a multi-step update, a concurrent write pattern, or a crash-recovery scenario? Describe it, and I can walk through which of the four properties applies and how your database’s default configuration handles it.