ACID (Atomicity, Consistency, Isolation, Durability) is a set of properties that guarantee database transactions are processed reliably even in the face of errors, power failures, or system crashes. These four properties ensure that data remains accurate and consistent, making ACID compliance a fundamental requirement for relational databases and financial systems.
ACID
ACID is the contract a database makes with the systems built on top of it: that a transaction either happens completely or not at all, and that once it is committed it stays committed. The acronym names four guarantees — Atomicity, Consistency, Isolation, and Durability — that together let developers reason about data as if only one thing is ever happening at a time, even when thousands of operations are racing through the same tables.
- Atomicity - A transaction is all-or-nothing; a partial write is never left behind after a crash.
- Consistency - Every transaction moves the database from one valid state to another, honoring its rules and constraints.
- Isolation - Concurrent transactions do not step on each other; each behaves as though it ran alone.
- Durability - Once committed, data survives power loss, crashes, and restarts.
Where it is used, ACID is usually invisible until it is missing. It underpins relational databases like PostgreSQL, MySQL, and SQL Server, and it is non-negotiable for the API-facing systems where correctness is the product — payments, banking, ledgers, inventory, and any workflow where a lost or duplicated write becomes a real-world liability. When designing an API over a data store, ACID is the property that lets an endpoint promise that a POST either fully succeeded or fully failed, which is why it remains a fundamental building block of trustworthy API operations even as eventually-consistent and distributed patterns grow around it.
