🚀 Introduction

Have you ever wondered how PostgreSQL can handle hundreds of concurrent updates and still feel blazing fast?

If Postgres tried to update every piece of data directly on disk at commit time, performance would slow down dramatically. Why? Because accessing and writing to random pages in memory and on disk is costly.

Instead, Postgres uses a smarter approach.

If you’re curious about the deep internals of how Postgres manages this trick — and want to walk away with a clear mental model of what happens when you run an UPDATE — keep reading. By the end of this article, you’ll be proficient in one of the most important mechanisms inside Postgres.

⌛ TL;DR

• PostgreSQL uses Write-Ahead Logging (WAL) to guarantee:
  • ⚡ Speed of writes (sequential log writes instead of random I/O)
  • 🔒 Durability (your data is safe once committed)
  • 🛠 Crash recovery (WAL can replay changes after a failure)
• Updating a row in Postgres = modify in shared buffers → log in WAL → flush WAL → commit → later write data file.

📝 What is WAL?

<aside> 💡

WAL (Write-Ahead Logging) is a fundamental technique in databases where all changes are first written to a sequential log before being applied to the actual data files.

</aside>

• Sequential writes are fast: Writing to a log file is much cheaper than random writes to many data pages.
• Crash safety: If the database crashes, WAL can be replayed to bring the data files back to a consistent state.
• Deferred writes: Data pages in memory (shared buffers) don’t need to be flushed immediately — WAL ensures the change is durable.

⛔ Without WAL:

• Every transaction would need to flush all modified data pages to disk before commit.
• This would be painfully slow, especially for random I/O.

✅ With WAL:

• Only a small sequential log write is needed at commit.