ACID Transaction Guarantees

ACID describes the guarantees a database tries to provide around a transaction, which is a group of reads and writes treated as one logical unit of work. The four letters stand for Atomicity, Consistency, Isolation, and Durability. They are often repeated as slogans, but each property points to a different failure mode that transaction processing has to control.

Atomicity means a transaction is applied as a whole or not at all. If a transfer moves money from one account to another, the debit and the credit must both happen, or neither should happen. The database achieves this with mechanisms such as undo records, write-ahead logging, or rollback segments. If the process crashes halfway through, recovery logic uses those records to discard partial effects. Atomicity is about incomplete work. It prevents the system from being left between states.

Consistency is the most overloaded term. In ACID, it does not mean the same thing as consistency in the CAP theorem. Here it means that a committed transaction leaves the database in a valid state according to declared rules: constraints, triggers, type checks, referential integrity, and application invariants. A transaction that violates a uniqueness constraint or creates an impossible balance should fail rather than commit bad data. The important caveat is that the database only enforces the rules it knows about. If a business invariant exists only in application code and that code is wrong, ACID does not save you.

Isolation means concurrent transactions should not interfere with each other in unsafe ways. Without isolation, one transaction could read another transaction's uncommitted changes, overwrite them silently, or observe a halfway-updated dataset. Databases implement isolation with locks, multiversion concurrency control, or a mix of both. Stronger isolation levels reduce anomalies but usually cost more in blocking, retries, memory, or throughput. Serialisable isolation is the cleanest mental model because it makes concurrent execution behave like some serial order, but it is also the hardest and most expensive guarantee to provide at scale.

Durability means that once a transaction is committed, its effects survive a crash that happens immediately afterwards. In a single-node database this usually relies on the commit record being flushed to durable storage before success is reported. In replicated systems the question becomes stricter: committed according to which replica set, and after how many acknowledgements? Durability therefore depends not only on the database engine but also on storage media, replication policy, and failure assumptions.

The tradeoffs appear when these properties meet real workloads. Higher isolation can reduce concurrency. Stronger durability can increase commit latency because more data must reach stable storage or peers before the client gets success. Some distributed databases relax parts of the model for availability or scale, especially across regions. Even traditional relational systems may expose configuration knobs that weaken guarantees in exchange for performance.

So ACID is best understood as a contract about transactional correctness, not as a marketing badge. It tells you what kinds of corruption and concurrency anomalies the system is designed to prevent. The useful engineering question is not “is this database ACID?” in the abstract. It is “which guarantees does this transaction path actually have under failure, concurrency, and replication?”