What Is ACID in Databases?

ACID is the set of four properties — atomicity, consistency, isolation, and durability — that together guarantee a database transaction is processed reliably, even in the face of errors, concurrent access, or system crashes. A database that upholds all four is described as ACID compliant, and a transaction that satisfies them is an ACID transaction.

The Four Properties

• Atomicity. A transaction is all-or-nothing. Either every operation inside it takes effect, or none of them do. If any step fails, the transaction is rolled back and the database is left as if it never ran.
• Consistency. A transaction moves the database from one valid state to another, never leaving it in a state that violates its rules, constraints, or invariants. (This is data-integrity consistency, which is different from the "consistency" in the CAP theorem.)
• Isolation. Concurrent transactions do not interfere with one another. The end result is as though they ran one at a time, in some serial order. Isolation levels — such as read committed, repeatable read, and serializable — let you choose how strictly this is enforced.
• Durability. Once a transaction commits, its changes are permanent and survive a crash, restart, or power loss, typically because they are written to durable storage such as a write-ahead log.

ACID Transactions and ACID Compliance

These properties are the foundation of relational databases such as PostgreSQL, MySQL, and Oracle, where every transaction is expected to be fully ACID. "ACID compliance" is a common requirement for systems that handle money, orders, or any data where a partial or corrupted update is unacceptable. The stronger the guarantees, however, the more coordination and overhead they demand — which is why some distributed systems relax them in favor of availability (see ACID vs BASE).

ACID in Valkey and Redis

Valkey and Redis provide some ACID properties but are not a drop-in replacement for a fully ACID relational database. Individual commands are atomic, and a native transaction (MULTI/EXEC) runs in isolation — no other client's commands interleave with it — but it offers no rollback if a command fails partway, so it is not atomic in the relational sense. Durability depends on how persistence is configured.

Redisson, the Valkey and Redis Java client, brings the behavior closer to what developers expect: its RTransaction adds genuine rollback and runs at READ_COMMITTED isolation, and through XA transactions and two-phase commit it can take part in distributed transactions that span a relational database alongside the cache.

For a hands-on guide with code, see How to Manage Transactions in Valkey and Redis on Java.