ACID Propertieslesson 4 of 4 · 2 min read

Durability

Committed means it survived the power cut

Durability promises that once a commit returns, the data survives whatever happens next: a crashed process, a kernel panic, a power cut.

That sounds obvious until you count the volatile layers sitting between your write and an actual flash cell. The row lands in the database's own buffers, then the operating system's page cache, then possibly a cache on the disk controller, and a power cut can vaporise all three.

The write-ahead log

The standard machinery is the write-ahead log. Before acknowledging a commit, the database appends a compact record of the change to a sequential log file and forces it through those caches to real storage. Only then does the commit return.

The table files themselves can be updated lazily, minutes later, because after a crash the database replays the log and rebuilds whatever the log promised. That is also why commits are fast: appending to a log is sequential, and the scattered writes into tables are deferred. The same idea powers message logs and most filesystems.

Durability is a dial with a price. Forcing data to disk costs you real time, roughly one to a few milliseconds, and it caps how many commits one of your connections can make.

So databases sell relaxations. Several will flush once a second instead of once per commit, and each option buys throughput by agreeing to lose up to a second of acknowledged writes in a crash. For your analytics counter that is fine. For your ledger it never is.

One machine's disk is still one machine. Serious systems extend the promise with synchronous replication, where a commit returns only once a second server also holds the log record. That turns surviving a crash into surviving the loss of the whole box, and costs a network round trip on every commit.

the shape of it

step 1 of 4

The commit is acknowledged only after the log record is forced to disk; table files catch up later.

Worked example

Omar runs Postgres for a small invoicing SaaS on a single cloud VM. Chasing benchmark numbers, he sets synchronous_commit = off and enjoys a 4x jump in write throughput. Two months later the VM's host has a power event at 09:41. Postgres restarts cleanly and replays its WAL, but the last 600 ms of acknowledged commits were never fsynced: 3 invoices that customers saw confirmed on screen do not exist anymore. One customer, a plumbing company, calls asking why invoice 4417 vanished. Omar restores the setting, accepts that commits now cost 2 ms, and adds a streaming replica with synchronous_standby so a lone VM dying can no longer eat acknowledged data. The benchmark number got worse and the product got honest.

ACID Properties: wrapping up

In the real world

01Stripe builds its money movement on ACID-transactional databases and pairs them with API idempotency keys, so a retried request cannot double-apply a charge that already committed.
02Postgres implements atomicity and isolation through MVCC row versions and durability through its write-ahead log, with synchronous_commit exposing the durability-versus-throughput dial per transaction.
03Amazon moved key retail systems to DynamoDB, which historically offered item-level atomicity and later added multi-item transactions (2018) because pure BASE semantics made order workflows painful.
04SQLite runs ACID transactions inside phones and browsers using a rollback journal or WAL mode, which is why an app killed mid-write reopens to an uncorrupted database.
05Kafka's storage layer is a durable append-only log with configurable acks (acks=all waits for replicas), the same write-ahead idea databases use, applied to a message stream.

Questions people ask

If my database is ACID, why do I still see race condition bugs?

ACID guarantees apply to what happens inside a transaction, at the isolation level you are actually running. Most databases default to Read Committed, which still allows anomalies like lost updates when you read, compute in the app, and write back. Fixes include doing the read-modify-write in one SQL statement, using SELECT FOR UPDATE, or raising the isolation level.

What does BASE mean and when is it acceptable?

BASE stands for Basically Available, Soft state, Eventually consistent, and it describes stores that relax ACID to gain availability and scale. It fits data where temporary staleness is harmless: feeds, counters, caches, analytics. It is a poor fit for money, inventory, or anything where two nodes briefly disagreeing creates real-world cost.

Does a COMMIT guarantee my data can never be lost?

It guarantees the data survived to stable storage on that machine, assuming full durability settings. It does not protect against the disk itself dying or the data center burning down. For those you need replication, ideally synchronous so the commit waits for a second machine, plus backups for the truly bad days.

Quick review

Atomicity:: all statements in a transaction succeed or all roll back. No partial writes
Consistency:: each transaction transitions DB from one valid state to another. Constraints enforced
Isolation:: concurrent transactions behave as if sequential. Controlled by isolation level (Read Committed, Serializable...)
Durability:: committed data survives crashes. Achieved via Write-Ahead Log (WAL) + fsync to disk
MVCC (Multi-Version Concurrency Control):: each write creates new row version. Readers see consistent snapshot without locking writers
BASE (NoSQL alternative):: Basically Available, Soft-state, Eventually consistent. Trades correctness for performance/availability

the trade-off

Every guarantee costs latency. Serializable isolation serializes contended work, durability waits on fsync, and the full set is hard to hold across shards. ACID also stops at the database edge, so a transaction that inserts an order and calls Stripe is not atomic no matter how the SQL is written.

in the room

ACID for financial transactions, inventory, anything requiring correctness. BASE for social media, analytics, caches.