WAL vs redo log vs undo log, mapped

WAL vs redo log vs undo log is not a choice among three interchangeable files. Write-ahead logging is an ordering rule. Redo and undo describe what recovery information can do.

A product may call its durable stream WAL, redo log, or transaction log. The same structure can support forward replay and rollback, or the engine can split those jobs across separate structures.

The reliable comparison asks two questions: what must reach durable storage before a data page, and can the recorded information replay a change, reverse it, or both?

WAL vs redo log vs undo log

The PostgreSQL WAL documentation gives the write-ahead rule directly. A changed data page may reach storage only after the WAL records describing that change have been flushed.

That ordering lets commit avoid flushing every dirty table and index page. The engine can sync a smaller sequential log, acknowledge the transaction, and write scattered data pages later.

Redo answers a different question. If a committed change is present in the log but absent from a data page after a crash, recovery can apply the change again.

Undo records enough old state or inverse information to reverse a change. It supports transaction rollback and, in some engines, reconstructs an older row version for a consistent read.

WAL can carry redo records, undo records, or records that support both actions. Calling WAL another word for redo hides the protocol behind one common implementation.

Fanout's write-ahead logging explainer derives the two ordering checks around a page LSN and a durable log position.

Redo follows no-force commits

No-force means commit does not force every changed data page to storage. It improves write behavior, but a crash can leave a committed update only in the log.

Redo closes that gap. Recovery starts from a checkpoint or recovery position and reapplies logged changes that the data files do not yet contain.

MySQL describes its InnoDB redo log as a disk structure for crash recovery. Changes missing from data files are replayed during startup.

The redo stream advances through log sequence numbers. Checkpoints mark how far data pages have caught up and therefore how much old redo space can be reused.

PostgreSQL uses the name WAL for this roll-forward stream. Oracle uses online redo logs. SQL Server calls the broader structure a transaction log.

The names differ, but the durability question is the same: can recovery reproduce committed work that was acknowledged before its data pages reached storage?

Undo follows steal and serves older reads

Steal means the buffer manager may write a dirty page before its transaction commits. A crash can therefore leave an uncommitted value in a data file.

One answer is undo information that restores the earlier state. The same information can support an explicit ROLLBACK before any crash occurs.

MySQL's undo log documentation says each record describes how to undo the latest change to a clustered-index record.

InnoDB also uses undo records for consistent reads. A transaction that needs an older value can reconstruct it from the stored unmodified data.

Oracle assigns a transaction to an undo segment when it first changes data.

Its transaction guide says undo stores old values for rollback and read consistency.

Undo is not automatically a separate file named undo.log. It can live in undo tablespaces, rollback segments, a shared transaction log, or row versions managed elsewhere.

One SQL Server log supports both directions

Every SQL Server database has a transaction log that records transactions and their database modifications.

Microsoft's transaction log documentation says startup recovery rolls forward changes missing from data files.

The same log is then used to roll back incomplete transactions. An application ROLLBACK also reads log records to reverse that transaction's modifications.

Calling this only a redo log would omit half of its recovery role. Calling it WAL describes its write discipline but still does not name every consumer of the stream.

The transaction log also feeds log backups, replication, availability groups, and log shipping. Those uses do not turn it into a different log each time.

Product documentation should win over a generic taxonomy. If an operator asks why the SQL Server transaction log cannot truncate, answer in SQL Server terms rather than renaming it WAL.

PostgreSQL keeps old tuples instead of an undo log

PostgreSQL documents WAL as the stream used for REDO after a crash. Its concurrency model keeps multiple row versions and decides visibility from transaction snapshots.

The PostgreSQL MVCC introduction explains that each statement sees a snapshot while concurrent updates create new versions.

An aborted transaction's tuples remain invisible rather than requiring a separate undo-log pass to restore an overwritten row in place.

That avoids a traditional undo structure for ordinary row rollback, but it does not erase cleanup work.

Dead tuple versions remain in table storage until vacuum can reclaim them.

This is why WAL and undo should not be treated as mandatory paired filenames. An engine can preserve atomicity through version visibility while still using WAL for durability and crash replay.

It also explains an operational difference. PostgreSQL rollback can finish by changing transaction state, while the physical space cleanup happens later.

Oracle and InnoDB split redo from undo

Oracle generates redo for changes to both data blocks and undo blocks. The redo stream can therefore reconstruct the undo state needed during recovery.

The Oracle transaction guide says a commit is durable when its commit record reaches the online redo log.

Undo segments retain old values for transaction rollback and consistent reads. Redo logs protect the changes, including changes made to those undo segments.

InnoDB uses a similar visible split in product terminology. Redo handles crash replay, while undo records reverse row changes and serve MVCC reads.

MySQL also has a server-level binary log for replication and point-in-time recovery.

It is not a substitute name for the InnoDB redo log.

The page-one results often compress these structures into "WAL equals redo." That shortcut works for one recovery path but fails as soon as undo blocks, MVCC reads, or replication logs enter the discussion.

SQLite shows why the product mode matters

SQLite defaults to a rollback journal. It copies original page content into that journal before modifying the database file.

In SQLite WAL mode, the original database file stays unchanged while new page versions are appended to a WAL file. A commit is a commit record appended to that file.

A checkpoint later copies committed WAL content back into the main database. Readers can continue using an earlier end mark while a writer appends newer changes.

The two SQLite modes make the direction concrete. The rollback journal preserves before-images for reversal. WAL mode preserves the old database and appends after-images for later checkpointing.

Saying "SQLite has WAL" is incomplete without the journal mode. The storage and concurrency behavior changes when the mode changes.

This is also why generic comparisons should not promise one universal file layout across database engines.

A four-step way to classify any database log

Start with the flush rule. Find the exact documentation that says which log position must be durable before a changed data page or commit acknowledgement.

Then inspect record contents. Determine whether records hold after-images, before-images, physical page changes, logical operations, or a mix.

Next, trace recovery. Ask whether startup repeats history, rolls uncommitted work back, marks versions invisible, or combines those steps.

Finally, list the other consumers: MVCC reads, replication, change data capture, backups, and point-in-time recovery.

Do not infer these roles from a filename. A transaction log may do redo and undo. A WAL stream may feed replication. An undo tablespace may also serve consistent reads.

The system design course is the next step for connecting these log mechanics to replication, failover, and recovery objectives.

WAL is the ordering promise. Redo moves state forward. Undo moves it back or reconstructs an older view. Product architecture decides which structures carry each role.