$Database Transactions

A transaction groups database operations into a unit with defined atomicity, consistency, isolation, and durability guarantees.

Jul 11, 2026

A database transaction groups reads and writes into a unit whose outcome is commit or rollback. The guarantees depend on the database engine, isolation level, constraints, and durability configuration; a transaction boundary alone does not make application logic correct.

ACID Map

• Atomicity defines whether the transaction’s writes take effect together.
• Consistency describes preservation of declared invariants before and after a transaction.
• Isolation controls which effects of concurrent transactions are observable.
• Durability defines what a successful commit promises after failure.

These properties are related but independent. For example, an atomic transaction can still violate an undeclared business invariant, and a durable commit can still be based on a stale read.

Concurrency

MVCC lets readers access appropriate row versions while concurrent writers proceed. MVCC does not remove all locking or prevent serialization anomalies. Applications still need atomic SQL operations, constraints, explicit locks, or serializable isolation for invariants that span reads and writes.

Transactions should be short. Do not hold database locks and versions open while waiting for HTTP calls, user input, message delivery, or slow computation. Persist intent, commit, perform external I/O outside the transaction, and reconcile the outcome.

Recovery

A Write-Ahead Log allows many engines to acknowledge commits before modified data pages are flushed to their final locations. Exact logging, undo, checkpoint, and recovery behavior is engine-specific.

Multiple Services

A local database transaction cannot atomically cover an unrelated service by itself.

• Distributed Commit Protocols coordinate participants that can prepare and later commit or abort.
• Saga Pattern sequences committed local transactions and uses semantic compensation after later failure.
• A transactional outbox connects a local state change to reliable message publication without performing network I/O inside the transaction.

The choice depends on participant capabilities, lock duration, availability requirements, compensation semantics, and operational tooling.