ACID is a set of properties that define how reliable database transactions should behave. The acronym stands for Atomicity, Consistency, Isolation, and Durability. Together, these principles ensure that data remains accurate, predictable, and safe — even in the presence of failures, concurrent users, or system crashes.
ACID is especially important for systems where correctness matters more than raw speed, such as financial, booking, and inventory systems.
Atomicity means that a transaction is treated as a single, indivisible unit of work.
Either:
All operations in the transaction succeed, or
None of them do
There is no partial completion.
For example, transferring money between two bank accounts involves:
Subtracting money from one account
Adding money to another account
If the system crashes after step one but before step two, atomicity ensures that the entire transaction is rolled back. The money is not lost or duplicated — the system returns to its previous state.
Consistency ensures that a transaction takes the database from one valid state to another valid state.
This means all defined rules are preserved, such as:
Data types
Constraints (e.g. non-null, unique keys)
Referential integrity
Business rules enforced by the database
If a transaction would violate any of these rules, it is rejected. Consistency does not mean that data is immediately consistent across distributed systems — it refers to correctness within the database itself.
Isolation ensures that concurrent transactions do not interfere with one another.
Even when multiple transactions run at the same time, each behaves as if it were running alone. Intermediate states from one transaction are not visible to others.
Databases provide different isolation levels, such as:
Read uncommitted
Read committed
Repeatable read
Serializable
Stronger isolation offers better correctness guarantees but can reduce performance due to locking or coordination.
Durability means that once a transaction is committed, its changes will persist — even in the event of a crash, power failure, or restart.
Databases achieve durability through:
Write-ahead logs
Persistent storage
Replication and backups
After a successful commit, the system guarantees that the data will not be lost.
ACID properties are critical because they provide trust.
They ensure that:
Data is not corrupted by partial failures
Concurrent users do not cause unpredictable results
Business rules are consistently enforced
Committed data is not lost
Without ACID, systems would require extensive custom logic to handle errors, retries, and recovery — increasing complexity and risk.
While some modern systems relax ACID guarantees to improve scalability or performance, many still rely on ACID transactions for their most critical operations.
ACID defines the foundation of reliable database transactions.
Atomicity prevents partial updates
Consistency enforces correctness rules
Isolation protects against concurrent interference
Durability ensures committed data survives failures
Together, these properties make databases dependable — and explain why ACID remains a cornerstone of system design decades after it was first defined.