ACID

The four promises behind reliable transactions: all-or-nothing writes, valid state, controlled concurrency, and durable commits.

what makes database transactions reliableall or nothing and survives a crashwhat does the acid in acid compliant actually meanacid complient databaseis my data still there after the power went outcan I trust committed data after a failuredoes the whole thing get undone if the server crasheswhy half a bank transfer does not get saved

See it

Live demo coming soon

What it is

ACID is shorthand for four transaction guarantees. Atomicity means all the transaction's writes commit or none do. Consistency means a successful transaction leaves declared rules intact. Isolation controls how concurrent transactions interfere and what they can see. Durability means committed data survives a crash under the database's persistence guarantees.

Harder and Reuter coined the acronym in a 1983 paper, and it has been a sales badge ever since. That is why 'ACID compliant' sits on database landing pages, and why MongoDB shipping multi-document transactions in 4.0 was treated as headline news rather than a point release.

Reach for ACID as a checklist when one operation moves money, inventory, permissions, or any state that cannot tolerate a half-finished write. It is not one switch called ACID: transactions supply atomicity, constraints help preserve consistency, isolation level and locking govern concurrency, and the storage system supplies durability.

Gotcha: ACID does not prove the business logic is correct. A transaction can atomically commit the wrong total, and weaker isolation can still allow anomalies your code did not expect. It also stops at the database boundary, so a rolled-back row cannot undo a Stripe charge or recall an email. Coordinate those effects with idempotency and a transactional outbox.

Ask AI for it

Make this order workflow satisfy the ACID guarantees in PostgreSQL. Wrap the order, line-item, and inventory writes in BEGIN and COMMIT with a ROLLBACK path; add CHECK, UNIQUE, and FOREIGN KEY constraints for the invariants; use SERIALIZABLE isolation and retry SQLSTATE 40001 with bounded exponential backoff; and keep Stripe API calls outside the transaction. Write a transactional outbox row in the same commit for each external effect, then dispatch it with an idempotency key. Include failure tests for a mid-transaction error, two concurrent purchases of the last item, and a process crash after commit.

You might have meant

database transactiontransaction isolationdatabase constraintdatabase lockidempotency