A database can report a transaction as committed while the data pages touched by that transaction are still absent from their final locations on disk. That behavior is not a contradiction. In systems built around write-ahead logging, durability is established by the log before the modified pages need to reach durable storage.
The distinction matters because a transaction changes several kinds of state at once. It changes the logical database, it changes in-memory page images, and it creates recovery information. Treating those as a single physical write obscures the mechanism that gives commit its meaning after a crash.
Write-ahead logging, commonly abbreviated WAL, separates the durable record of a change from the eventual placement of that change in database pages. The ordering constraint is the central idea: recovery information describing a modification must become durable before a dirty page containing that modification can be written in a form that recovery might later encounter.
Commit is a durability boundary, not a page-flush boundary
Consider a transaction that updates two rows stored on two different pages. A buffer manager may already have both pages in memory. Applying the updates can therefore modify only memory at first.
For a WAL-based engine, forcing both complete pages to durable storage at commit is unnecessary. The engine can instead append records describing the transaction’s changes to a sequential log and make the required portion of that log durable. Once the commit record and the log records needed to reconstruct the transaction satisfy the engine’s durability rules, the transaction can be acknowledged as committed.
The dirty pages can remain in the buffer cache. They may be written later by a background process, by checkpoint activity, or because the buffer manager needs space.
This separation has an important consequence: the state visible in database files immediately after a commit is not necessarily a complete physical image of all committed transactions. The durable log supplies the missing history needed to reconstruct a valid state after restart.
The exact persistence primitive depends on the database, operating system, filesystem, and storage configuration. A successful application-level write into a kernel buffer is not automatically equivalent to durable media persistence. Database guarantees therefore depend on the documented behavior of the engine and its configured durability settings, not merely on the presence of a log file.
The write-ahead rule protects recovery
The phrase write ahead describes an ordering requirement. Before a database page containing a particular change is allowed to reach persistent storage, the corresponding recovery information must already be persistent according to the engine’s durability model.
Without that order, a crash can expose a page change for which no durable recovery record exists.
Suppose page P contains balance data. Transaction T7 changes the page in memory and generates log record L7. If the database writes the changed page to storage first, then crashes before L7 becomes durable, restart code can observe the changed page without possessing the record needed to reason correctly about that change. If T7 had not committed, recovery might lack the information required to reverse it.
WAL reverses the risky order:
create L7
|
persist L7
|
page P may be flushedThe rule applies to the relationship between log progress and page progress. It does not require every log record to be forced individually. Engines can buffer log records and persist batches while still preserving the required ordering.
Redo and undo depend on the recovery model
A log is useful only if restart processing can interpret it. Different database engines use different recovery algorithms, so a generic description has to separate properties that are common from properties that depend on implementation.
A redo-capable log records enough information to repeat changes that belong in the recovered state but are missing from data pages. This can happen when a transaction committed, its log became durable, and the process crashed before all of its dirty pages were flushed.
Undo information addresses the opposite case in recovery schemes that permit uncommitted changes to reach persistent pages. If a dirty page containing an uncommitted update was flushed before a crash, recovery needs enough information to remove the effect of that transaction, or an equivalent mechanism that restores a valid state.
Not every engine exposes the same redo/undo structure. Some use physical page-oriented records, some encode logical operations in parts of the system, and some combine approaches. The stable engineering point is that the log format and buffer-management policy are designed together. A policy that permits certain page states to reach storage requires recovery information capable of handling those states.
This coupling is easy to miss at an API boundary. An application sees COMMIT; the storage engine sees a protocol among log sequence positions, dirty pages, transaction state, and durable writes.
Log sequence positions connect pages to history
WAL implementations commonly assign monotonically advancing positions or sequence numbers to log records. A page can record the position associated with its most recent logged change. Recovery and buffer management can then compare page state with log state.
The exact names differ across engines, but the ordering role is similar. A page carrying a change associated with log position N must not outrun the durable log past the constraints required by the engine. During recovery, sequence information can also help determine whether a logged operation has already been reflected in a page.
This is more precise than treating the log as a text journal of SQL statements. Recovery generally needs an ordering relation tied closely to storage mutations. Re-executing original application statements would also be problematic: statement results can depend on concurrent state, nondeterministic functions, indexes, triggers, or other context that no longer matches the original execution.
A recovery log is therefore part of the storage engine’s state machine, not merely an audit trail.
Group commit changes latency without changing transaction order
Forcing durable storage can be expensive relative to modifying memory. A database can amortize that cost by allowing several transactions to share one log flush.
Assume three transactions reach their commit points close together:
T1 commit record \
T2 commit record > append to log -> one durable flush
T3 commit record /If the flush makes the log durable through the position containing all three commit records, each transaction can satisfy the same durability boundary with one shared persistence operation. This is group commit.
Group commit does not imply that the transactions become one transaction. Their isolation and serialization behavior remains governed by the engine’s concurrency-control rules. The batching concerns the physical act of making an already ordered prefix of the log durable.
The latency effect is conditional. Batching can reduce the number of persistence operations per transaction under concurrent load, but a transaction may wait briefly for a batch to form or for another transaction’s flush to complete. Engines choose different policies, and storage devices have different flush characteristics. The useful abstraction is that commit acknowledgment can be coordinated around a durable log position rather than around one independent device flush per transaction.
Checkpoints bound recovery work
If data pages were never flushed, restart processing could need to replay an arbitrarily long history. Databases therefore combine WAL with checkpoint mechanisms that establish recovery landmarks and advance persistent page state.
A checkpoint does not necessarily mean that every dirty page is synchronously written at one instant. Many engines use fuzzy or incremental checkpoint techniques that allow normal work to continue while checkpoint-related writes progress.
The purpose is broader than producing a perfectly synchronized snapshot. Checkpoint metadata and page flushing give recovery a bounded or reduced region of log history to examine, according to the engine’s algorithm.
This also explains a common operational distinction between log retention and checkpoint progress. A log segment that is no longer needed for crash recovery might still be required for replication, point-in-time recovery, archival, or another feature. Reclaiming log storage is therefore governed by every consumer that can retain a dependency on old log positions.
Durability settings can move the acknowledgment point
The statement that commit waits for durable WAL is only valid when the configured transaction durability requires it.
Some database systems provide modes that acknowledge a commit before its log records have reached the strongest available persistence boundary. Such modes can reduce commit latency, but a process, operating-system, or power failure can then lose transactions that had already been acknowledged, depending on the exact mode and failure.
That trade is semantic, not merely a tuning detail. Once an application receives success, it may emit an external message, return a response, release a lock, or permit another operation to depend on the committed state. If the database configuration allows acknowledged transactions to disappear after a qualifying failure, application reasoning must account for that possibility.
Replication adds another boundary. A local WAL flush can establish durability on one database instance without establishing durability on another replica. Synchronous replication modes can move the acknowledgment condition to include remote receipt, remote persistence, or other documented milestones. Those guarantees are specific to the replication protocol and configuration.
The word committed therefore needs a concrete durability contract. WAL supplies the mechanism for a local storage boundary, while configuration determines the point at which the engine tells its caller that the boundary has been crossed.
The log is part of the database state
WAL is sometimes described as a performance optimization because sequential log writes can avoid forcing scattered data pages at every commit. That description is incomplete. The log is also part of the correctness protocol that makes deferred page writes recoverable.
A dirty page, a log position, and a commit acknowledgment participate in one ordering discipline. The database can postpone expensive page placement precisely because it has first preserved enough ordered information to recover the intended state.
This changes the interpretation of persistence inside a storage engine. Durability does not require every logical change to occupy its final page location before success is returned. It requires the engine to cross a documented recovery boundary from which committed state can be reconstructed after the failures covered by its guarantee.
That boundary is the real meaning carried by commit in a WAL-based system.