ACID Compliance
Term 11 of 68 in the ERPStack technical glossary
What is ACID Compliance?
ACID compliance is a set of database transaction properties (Atomicity, Consistency, Isolation, Durability) that guarantee database transactions are processed reliably, maintaining data integrity even in the event of crashes or power outages.
ACID Compliance at a glance
- The 4 properties
- Atomicity, Consistency, Isolation, Durability — all 4 or the guarantee is not ACID
- Isolation levels
- PostgreSQL 18 offers 3: Read Committed (default), Repeatable Read and Serializable
- Durability
- Write-ahead logging, so a commit survives a power loss 1 millisecond later
- Where it ends
- At the database boundary — 2 services need the Saga Pattern instead
- Built with
- PostgreSQL 18 transactions through Drizzle ORM 0.45 in Next.js 16 server actions, exercised by Vitest 4 and Playwright 1.59 in GitHub Actions before any Vercel or AWS deploy
- Numbers that matter
- 4 properties, all required; 3 isolation levels in PostgreSQL 18; 1 commit covering every table in the change; 0 partial states visible
- Compare with
- MongoDB Atlas document-scoped guarantees, Redis without durability configured, or the Saga Pattern once 2 services are involved
- Commonly paired with
- An Immutable Audit Trail, Drizzle ORM 0.45 transactions, Idempotency in API Design, the Saga Pattern and Next.js 16 server actions
- Where it is non-negotiable
- finance, insurance and logistics ledgers: 1 posting that debits and credits inside the same Postgres transaction, or the trial balance stops reconciling.
How ACID Compliance works in production
The ERPStack approach to ACID Compliance
We enforce strict ACID compliance using PostgreSQL transactions wrapped in Drizzle ORM database sessions. This guarantees that balance ledgers and inventory counts never logically drift.
Frequently asked questions about ACID Compliance
What do the 4 letters in ACID Compliance mean?
Atomicity means a transaction fully happens or fully does not. Consistency means it moves the database between valid states, honouring every constraint. Isolation means concurrent transactions do not observe each other's partial work. Durability means a committed result survives a crash. ACID Compliance requires all 4 together; a system offering 3 of them has failure modes that only appear under concurrency or hardware failure.
Why does ACID matter for financial data?
Because partial success is indistinguishable from corruption. Moving money debits 1 account and credits another, and ACID Compliance is what guarantees those 2 writes commit together or not at all. Without it, a crash between the statements leaves funds that exist nowhere. Every reconciliation process in accounting exists to catch exactly this class of error in systems that could not prevent it.
Which isolation level should you use?
Read Committed is the PostgreSQL 18 default and is correct for most work. Repeatable Read prevents a transaction seeing changed rows mid-flight, which matters for multi-step reads that must agree. Serializable gives full ACID Compliance semantics as if transactions ran 1 at a time, at the cost of retries under contention. Choosing the strongest level everywhere trades throughput for a guarantee most statements do not need.
Do NoSQL databases give up ACID entirely?
Not entirely, but usually at a smaller scope. Many document stores provide ACID Compliance within 1 document or 1 partition while offering weaker guarantees across them, which is a reasonable trade for some workloads and a poor one for ledgers. The important thing is knowing which scope you have: assuming a cross-document transaction exists when it does not produces data errors that surface long after the code shipped.