WAL - What is Write-Ahead Logging in postgres Database Internal Architecture

 I'll focus on the WAL (Write-Ahead Logging) system from the PostgreSQL architecture diagram,  because its the only thing there that I’d never heard of before and turns out it's crucial for database reliability and ACID compliance and also

So What is Write-Ahead Logging?

Write-Ahead Logging is a mechanism where changes to the database (modifications to data pages) are recorded in a special log file (WAL file) before they are actually written to the main database files. This log is used to ensure data integrity and to recover the database in case of a crash or failure.

Or to put it simply: Imagine you’re building with blocks:

1. Before you add or remove any block, you write down your plan in a notebook: "I'm going to add a red block on top."

2. Then you go ahead and add the block.

WAL does the same thing:

• Before saving changes to the database, it writes down those changes in a special log file.

• If something crashes, the database reads the log and "replays" the steps to restore everything to how it should be.

Benefits of WAL

Crash Recovery:

• WAL ensures the database can be restored to a consistent state after a crash by replaying the logs.

High Performance:

• Logging changes in WAL is typically faster than directly writing to data files because writes to WAL are sequential.

Transaction Safety

• Ensures database consistency

• Prevents partial updates

ACID Compliance: The WAL system is essential for several ACID properties:

Atomicity -All or Nothing:

• WAL ensures that either the entire transaction is completed or none of it is applied.If a transaction fails, PostgreSQL can use the WAL to undo partial changes

• The WAL contains both redo records (for completing transactions) and undo records (for rolling back)

Consistency -Everything Stays Valid:

• When something goes wrong (like a crash), PostgreSQL replays the WAL logs step-by-step. This process guarantees the database moves from one valid complete state to another, without missing or corrupting any data.

• All changes are logged completely before being applied to the actual data files

Isolation-Transactions Don't Mix:

• WAL works in conjunction with transaction isolation mechanisms to ensure concurrent transactions don't interfere with each other.

• Changes from one transaction aren't visible to other transactions until completed

Durability-Changes Are Permanent:

• Once a transaction is committed, its changes are guaranteed to persist, thanks to WAL. Changes survive system crashes or failures.

Let me give you a real-world example of how WAL helps in a banking transaction.

Real-World Banking Scenario: Imagine you're transferring $1,000 from your Chase savings to your checking account and the bank's power goes out mid-transaction.

Without WAL:

1. Deduct $1000 from savings

*POWER FAILURE*

2. Add $1000 to checking (never happens)

Result: You just lost $1,000 because the money was taken from savings but never added to checking!

With WAL:

1. Write to WAL: "Plan to move $1000 from Account A to B"

2. Write to WAL: "Deducted $1000 from savings"

*POWER FAILURE*

When the system comes back:

1. Database reads WAL

2. Sees the transaction wasn't completed

3. Either:

• Rolls back the savings deduction OR

• Completes the checking deposit

Result: Your money is safe! You either have:

• Original amount in savings (rolled back)

• OR correct amounts in both accounts (completed)

And that is WAL as far  as I understood