--- title: "Write-ahead log vs transaction log" description: "Separate the WAL ordering rule from a database transaction log, then trace one SQL Server update through commit, redo, undo, and truncation." canonical_url: "https://fanout.sh/blog/write-ahead-log-vs-transaction-log" md_url: "https://fanout.sh/blog/write-ahead-log-vs-transaction-log.md" last_updated: "2026-08-23" access: "public" --- # Write-ahead log vs transaction log Separate the WAL ordering rule from a database transaction log, then trace one SQL Server update through commit, redo, undo, and truncation. - Author: Suraj Gaud - Published: 2026-08-23 - Track: System design - Access: Public - Tags: write-ahead log, transaction log, WAL, database recovery, SQL Server, PostgreSQL, redo, undo, transactions Write-ahead log vs transaction log is usually not a choice between two files. Write-ahead logging is an ordering rule. A transaction log is the ordered record stream a database keeps for transactions and recovery. One transaction log can follow the WAL rule. SQL Server says exactly that: it uses a write-ahead logging algorithm for its transaction log. The names diverge because products expose different record formats, recovery models, backup tools, and replication uses around the same log-first invariant. ## Write-ahead log vs transaction log The WAL rule says a database must make a change's log record durable before it writes the changed data page to durable storage. It also needs a durable commit record before reporting a durable commit to the client. Fanout's[WAL crash walkthrough](/blog/write-ahead-log-explained)traces those two boundaries in detail. A transaction log is a concrete sequence of records. It may contain transaction starts and ends, row or page changes, allocation changes, commit records, rollback work, and checkpoint information. [Microsoft's transaction-log guide](https://learn.microsoft.com/en-us/sql/relational-databases/sql-server-transaction-log-architecture-and-management-guide?view=sql-server-ver16)calls its own structure a write-ahead transaction log. [PostgreSQL documentation](https://www.postgresql.org/docs/current/wal-intro.html)calls the structure WAL and emphasizes redo: logged changes can reconstruct data pages that were not flushed before a crash. The label alone does not tell you whether the records are physical, logical, redo-only, or paired with a separate undo structure. ## Trace one update through SQL Server Suppose a transaction changes an account balance from 500 to 400. SQL Server updates the page in its buffer pool and marks that cached page dirty. It also creates a transaction-log record in a log block in memory. The record has a log sequence number, or LSN, that places it in the ordered stream. The dirty page does not need to reach the data file at commit. That is the no-force benefit: the client can finish after the smaller sequential log write becomes durable. The page cannot reach the data file first. SQL Server prevents the flush until the log is durable through the record describing that page change. At commit, the relevant log records are flushed. Later, a checkpoint can write the dirty page to its data file. If the server crashes after commit but before the page flush, recovery reads the transaction log and rolls the missing change forward. The same sequence has both names. The file and records are the transaction log. The rule that orders log durability before page durability is WAL. Most page-one explanations define WAL without saying that a product's "transaction log" may be its WAL implementation. ## A transaction log can carry more than redo WAL does not prescribe one record schema. It states the durability order needed before a data page can be written. SQL Server records the transaction ID on each related record and links a transaction's records with backward pointers. That chain lets rollback visit one transaction's work in reverse. Its data-modification records can describe a logical operation or store before and after images. Recovery can roll an operation forward or reverse it according to the record type. The transaction log also records transaction boundaries, page and extent allocation, and structural operations such as creating an index. These contents support atomicity as well as durability. A committed change missing from a data file can be redone. An incomplete transaction reflected on disk can be undone. The write-ahead rule makes both operations possible by preventing a dirty page from outrunning the durable evidence needed to interpret it. A database can store undo elsewhere.[Oracle](https://docs.oracle.com/en/database/oracle/oracle-database/19/admin/managing-undo.html), for example, separates undo records from its redo stream. That product vocabulary still does not change the WAL ordering question. Ask what the log contains and how recovery uses it. "It has a WAL" is not enough to answer either question. ## Product names describe different operating surfaces PostgreSQL exposes WAL segment archiving, replication positions, checkpoints, and point-in-time recovery around a stream of redo records. SQL Server exposes transaction-log files, virtual log files, recovery models, log backups, LSN chains, and truncation rules. Those surfaces lead users to treat WAL and transaction log as different categories. They are better understood as protocol and product structure. The top Google result for the exact comparison is a short Reddit question. Other first-page articles mostly explain WAL in isolation or describe SQL Server's transaction log without naming the category error. [SQLShack connects the two](https://www.sqlshack.com/sql-server-transaction-log-part-1-log-structure-write-ahead-logging-wal-algorithm/). Log records live in transaction-log blocks, and WAL controls when those blocks must reach disk. Another engine may call a similar durable stream a redo log, journal, or commit log. Those terms can overlap, but none is safe to equate without reading the engine's recovery contract. A commit log may only record transaction status. A replication log may keep logical events for subscribers. A recovery log may retain physical page changes that an application consumer cannot use. Names are hints. Durability order, record contents, and retention are the actual design. ## Redo, undo, backup, and replication are separate jobs Redo reapplies a committed effect that is present in the durable log but absent from a data page. Undo removes an incomplete transaction's effect when that effect reached persistent data before the crash. A steal buffer policy creates this possibility by allowing uncommitted dirty pages to flush. SQL Server recovery can therefore roll forward missing modifications and roll back incomplete transactions. Its transaction log stores the ordering and transaction links needed for both. PostgreSQL's WAL documentation focuses on roll-forward recovery, while PostgreSQL's MVCC and transaction-status machinery determine which row versions are visible. Log backups are another use. SQL Server can preserve a continuous log chain after a full backup and replay those backups to a recovery point. Replication may read or ship the same underlying record stream, but it adds an acknowledgement policy and another failure domain. Local WAL durability does not prove that a replica has the commit. Change data capture adds consumer contracts, schema interpretation, and retention pressure. A recovery log can be the source for CDC without becoming a general application event log. The same bytes can serve several jobs. The guarantees of each job still need to be named separately. ## Checkpoints and truncation do not change the definition A checkpoint reduces recovery work by making progress on dirty pages and recording a later recovery boundary. It does not replace WAL. The database must still make every relevant log record durable before a checkpoint writes the corresponding dirty page. SQL Server's transaction log is logically circular. Inactive virtual log files can be marked reusable once they fall before the minimum LSN still needed for recovery. Under the full recovery model, log backups participate in when space can be reused. Under the simple model, checkpoints can make inactive space reusable sooner. PostgreSQL recycles or archives WAL segments according to its own checkpoint, replication, and recovery settings. An unexpectedly large log therefore points to a retention boundary, not a semantic difference between WAL and a transaction log. Look for a long transaction, a lagging replica, an unperformed log backup, an old replication slot, or another consumer holding the required LSN. Deleting a log file by hand is not a valid fix. The file may contain the only durable copy of a committed change or the records required to make the data files consistent. ## Use three questions instead of two labels When a design says "use a WAL" or "write to the transaction log," ask three questions. First, what must be durable before the system acknowledges commit? Name the commit record, storage boundary, and replica policy. Second, what information does each record carry? Identify redo data, undo data, transaction status, logical operations, physical images, and page or transaction links. Third, how long must the records remain? Recovery, rollback, backup, replication, and CDC can hold different low-water marks. The[Fanout write-ahead-log implementation](/system/implementations/write-ahead-log)is a useful continuation for seeing records, commit, and recovery as one mechanism. If a product says "transaction log," do not assume it violates or replaces WAL. Check whether its log records become durable before its dirty data pages. If a product says "WAL," do not assume the file contains every transaction detail or supports arbitrary replay consumers. Write-ahead logging states the ordering guarantee. The transaction log is one database's durable record stream and operating surface for enforcing that guarantee. --- This representation contains public Fanout content only. Protected Pro lessons, account data, billing, checkout, and pricing are not included. Browse the public content map: https://fanout.sh/sitemap.md