ACID Transactions definition
ACID transactions are database operations that guarantee Atomicity, Consistency, Isolation and Durability. A transaction groups several reads and writes so they either all succeed or all fail, never leave data in a broken state, do not interfere with concurrent transactions and survive crashes once committed. ACID is the foundation of reliable relational databases such as PostgreSQL.
The four ACID properties
A bank transfer that debits one account and credits another is the classic example, because a half-finished transfer would create or destroy money. Each of the four properties protects against a different way that could go wrong:
- Atomicity: all operations in the transaction commit together or none do; a failure midway rolls everything back
- Consistency: the transaction moves the database from one valid state to another, respecting constraints such as foreign keys and unique indexes
- Isolation: concurrent transactions do not see each other's partial work, as if they ran one after another
- Durability: once committed, data survives crashes and power loss, typically through a write-ahead log on disk
Isolation levels in practice
Full isolation is expensive, so databases offer levels that trade strictness for concurrency. Read committed, the default in PostgreSQL, prevents reading uncommitted data but allows a value to change between two reads in the same transaction. Repeatable read, the default in MySQL's InnoDB engine, keeps reads stable within a transaction. Serializable behaves as if transactions ran one at a time and may abort transactions that conflict.
Many real bugs, such as overselling the last item in stock or redeeming a voucher twice, come from assuming stronger isolation than the database provides. Fixes include row locks with SELECT ... FOR UPDATE, optimistic concurrency with version columns, unique constraints, and serializable transactions with automatic retries.
Keep transactions short. Long transactions hold locks, block other users, bloat storage in databases such as PostgreSQL and increase the chance of deadlocks. Do slow work, such as calling a payment provider or sending email, outside the transaction, and record its outcome in a second, quick transaction.
ACID vs BASE
BASE (basically available, soft state, eventually consistent) describes many distributed NoSQL systems that relax consistency to stay available and fast across nodes and regions. Writes may take time to appear everywhere, and applications must tolerate stale reads. The trade-off follows from the CAP theorem: during a network partition, a distributed system must choose between consistency and availability.
The line has blurred. MongoDB supports multi-document ACID transactions, DynamoDB offers transactional APIs, and distributed SQL databases such as CockroachDB, YugabyteDB and Google Spanner provide ACID guarantees across regions. Our SQL vs NoSQL comparison covers how to choose.
Transactions across services
ACID applies within one database. When a business operation spans several services or databases, such as an order service and a payment service in a microservices architecture, there is no single transaction to roll back. Teams use sagas, where each step has a compensating action, and the transactional outbox, which writes the business change and an event in one local transaction so the event is never lost.
Nexzem designs these flows carefully for payment and order systems, where partial failures cost real money, choosing a single well-structured database where possible because one ACID transaction is far simpler, faster and easier to reason about than any distributed alternative, however well it is engineered.