Does durability require every changed data page to be written before success?

Not necessarily. Durable recovery information can support later reconstruction.

Can a durable database be temporarily unavailable?

Yes. Recovery or replacement of a failed server can take time while committed information remains preserved.

Does asynchronous commit always corrupt the database after a crash?

No. It can allow loss of recent transactions while recovery still produces a consistent earlier state; exact behavior depends on the system.

AI Glossary / Data engineering and architecture / Intermediate

Durability (database systems)

Definition

Durability in database systems is the property that a committed transaction's effects survive the failures covered by the system's guarantee. It is the D in ACID, alongside atomicity, consistency and isolation.

What it means

A screen displaying “saved” creates an expectation: restarting the service should not quietly erase that work. Durability connects that expectation to a defined database commitment. A change held only in ordinary working memory can disappear when power is lost, even though a running application could read it before the failure.

The guarantee has a boundary. Surviving a database process crash is different from surviving destruction of every storage device. Teams must identify which failures, storage arrangements and operating settings their commitment covers.

Durability also differs from availability. Records can remain recoverable while a service is offline. Conversely, a service can restart quickly yet have lost its latest acknowledged changes. Neither speed of restart nor a successful read alone establishes durability.

How it works

A common mechanism is write-ahead logging. The system preserves the information needed to recover changes in a durable log before acknowledging the required commitment. Recovery can use that information even when ordinary database pages had not all reached their final locations before the crash.

The whole storage path matters. Operating systems, controllers and drives may buffer writes. A database depends on the relevant persistence operations and hardware honoring their guarantees; moving bytes into another volatile cache is insufficient.

Some configurations deliberately acknowledge transactions before the relevant log information becomes durable. That can reduce waiting but permits loss of recent acknowledged work after a crash. Grouping several transactions into one durable flush is a different optimization: sharing a flush need not mean acknowledging before it completes.

Replication and backups address additional failure and recovery needs. Their contribution depends on where copies exist, when they are updated and what must finish before success is returned.

Three practical examples

An order service preserves a confirmed order through a server restart, so warehouse staff can retrieve the same commitment afterwards.
A data platform distinguishes reconstructible temporary calculations from original customer submissions when setting recovery requirements.
An AI review tool records the accepted human correction durably before telling the reviewer that the change has been saved.

Think of it this way

Think of a clerk issuing a receipt after entering an order in a protected register. A note left only on a loose working pad offers a different level of assurance. The relevant question is what must happen before the receipt is issued.

The analogy is limited: database recovery uses precise storage protocols, and a protected register can still be destroyed. Durability always depends on the failures included in the promise.

Worked example

Comparing two acknowledgment rules

Consider two invented configurations, each processing ten updates. In configuration A, success is returned only after the recovery information for each acknowledged update is durable. In configuration B, all ten updates are acknowledged immediately, but only the first seven have reached durable storage when power fails.

Assume the durable storage survives and recovery operates correctly. A must retain its acknowledged updates under this failure model. B may recover seven and lose the final three: 3 ÷ 10 = 30% of that small illustrated group.

The 30% is not a general loss rate. It results from this selected failure instant. Waiting longer before the failure could change the result. Nor does losing the last three necessarily mean the remaining database is internally corrupted. The example separates acknowledgment timing, preservation of recent work and consistency of recovered data.

Illustrative case study

A fictional equipment-hire business adds a conversational assistant for changing collection times. During an exercise, a customer sees confirmation, the service restarts, and the old time reappears. The team first checks whether the assistant merely updated its conversation memory or actually committed the booking change.

It then traces the database acknowledgment policy and tests recovery with the storage arrangement used in production. The customer-facing confirmation is tied to the required saved booking state, with uncertain outcomes handled explicitly.

The business also rehearses restoring an earlier record after an authorized but mistaken edit. Durability would preserve that mistaken edit too; recovery from human error requires history or backup arrangements beyond the basic commit guarantee. This scenario illustrates requirements, not a measured company result.

Common misconceptions and mistakes

Durable means indestructible. Guarantees cover stated failures; losing every applicable copy can exceed them.
A replica is automatically a backup. An unwanted deletion may reach replicas as intended.
A fast restart proves no data was lost. Availability and preservation require separate evidence.
Durability makes an incorrect update correct. It preserves committed effects, including mistakes.

Business use

Ask what “saved” means for each important workflow. Identify which event permits a confirmation message, what failures the storage promise covers, and how recovery demonstrates that acknowledged records remain.

A useful acceptance exercise compares acknowledged transaction identifiers with records recovered after a controlled failure. Keep this separate from restoration exercises for accidental deletion or broader disasters. For AI applications, distinguish replaceable derived outputs from user approvals, original evidence and actions that other systems have already relied upon.

The practical decision is a business requirement matched to a documented persistence policy, rather than an assumption attached to the word database.

Check your understanding

A service recovers all committed bookings after a restart but takes twenty minutes to return online. Has that delay alone disproved durability?

Answer: No. The delay concerns availability and recovery time. Durability concerns preserving the committed effects under the stated failure assumptions.

Related terms

Commit (data management)
Replication (statistics)
Backup
ACID
transaction
write-ahead logging
commit
replication
recovery point objective

Learn next

Read write-ahead logging and recovery point objective. Trace one confirmation message from your application to its database acknowledgment and document what that acknowledgment guarantees after a failure.

Sources

PostgreSQL documentation, Reliability: https://www.postgresql.org/docs/18/wal-reliability.html. Primary explanation of persistence and storage assumptions.

PostgreSQL documentation, Asynchronous Commit: https://www.postgresql.org/docs/17/wal-async-commit.html. Primary account of acknowledgment timing, potential recent-transaction loss and group commit. The numerical example and business case are original illustrations.

Previous: Duplicated sample Next: Duration