Durability guarantees that once a transaction has committed, its effects survive — even a power loss or crash the instant after the commit acknowledgment is returned. This one sounds obvious until you consider the mechanism: how does a database guarantee data made it to permanent storage, immediately, on every single commit, without every write being unbearably slow?
The standard answer is a write-ahead log (WAL): before any change is applied to the actual data files, it's first appended to a sequential log file on durable storage, and the transaction is only reported as "committed" once that log entry itself is confirmed durable. The data files can be updated later, lazily, in the background — because if the process crashes before that happens, recovery just replays the WAL from the last checkpoint to reconstruct every committed change.
Without a WAL: every commit requires an in-place random-access write to the
data file — slow, and if it's interrupted mid-write, the data file is now
corrupted with no way to tell what state it was in.
With a WAL: every commit requires one sequential append to a log file —
fast — and the data file is updated later from that log, where an
interruption just means replaying the log again on restart.
This is also why durability and performance trade off directly in practice: some systems offer a "fsync every commit" mode (fully durable, slower) versus an "fsync periodically" mode (a small window of possibly-lost commits on a hard crash, much faster) — a real, explicit choice many databases expose as a configuration setting, because not every application needs the strongest possible durability guarantee for every write.