ACID (Atomicity, Consistency, Isolation, Durability)

ACID is the promise a serious database makes about transactions: all of the change or none of it, always coherent, never half-visible, never forgotten. It is why a bank transfer cannot debit one account and mysteriously fail to credit the other — and why 'the system crashed mid-update' is a bug, not a Tuesday.

What It Is

ACID is the set of guarantees a transactional database provides: Atomicity — a transaction's changes apply entirely or not at all (no half-completed transfers); Consistency — data moves between valid states, never violating defined rules; Isolation — concurrent transactions behave as if executed one at a time (no transaction sees another's half-done work); Durability — once committed, a change survives crashes and power loss. The guarantees cost performance, which is why some modern systems relax them (BASE, eventual consistency) for scale — trading the appearance of instant coherence across distributed systems for throughput.

Why It Matters to You

This is the property your auditors, your CFO and your regulators assume exists whether or not anyone names it. When it matters: money, inventory, allocations — anything where a half-applied change is an error with legal or financial weight. The executive question surfaces in architecture reviews and vendor due diligence: does this system provide transactional guarantees for the operations that need them, and if it relaxes consistency for scale (as some distributed and AI-era systems do), what does the user experience during the window of incoherence — and what does the audit trail show? 'Eventually consistent' is an engineering trade-off, not an excuse; systems that need ACID and lack it fail in auditable ways.

When You'll Meet It

In architecture reviews and any system handling financial or legal state. Ask where transactions are guaranteed — and treat vague answers about the money paths as findings.