How to Move PostgreSQL WAL Files to a Dedicated Disk for Better Performance (Step-by-Step Guide)

 

Moving PostgreSQL WAL Files to a Dedicated Disk: A Complete Guide

In my previous post, I covered installing PostgreSQL 18 with a performance-optimized disk layout. Today, I'm diving deeper into one of the most impactful optimizations you can make: relocating your Write-Ahead Log (WAL) files to a dedicated disk volume.

This seemingly simple change can dramatically reduce I/O contention and boost your database performance, especially for write-heavy workloads. Let me show you exactly how to do it safely.

What Are WAL Files and Why Do They Matter?

Write-Ahead Logs are the backbone of PostgreSQL's durability guarantees. They're sequential transaction logs that record every change made to your database before those changes hit the actual data files. Think of them as a detailed journal of everything happening in your database.

WAL files serve two critical purposes:

Crash Recovery: If PostgreSQL crashes unexpectedly, WAL files allow the database to replay transactions and restore consistency.

Point-in-Time Recovery and Replication: WAL files enable you to recover your database to any specific moment in time and support streaming replication to standby servers.

By default, these files live in the pg_wal directory inside your PostgreSQL data directory (PGDATA). While convenient, this setup creates performance challenges.

The Performance Problem

Here's the issue: WAL files have completely different I/O characteristics than your regular data files. WAL writes are purely sequential—they write transaction records one after another in order. Your data files, however, experience random read and write patterns as users query different parts of your database.

When these two conflicting I/O patterns share the same disk, they interfere with each other. Your sequential WAL writes get interrupted by random data file operations, and vice versa. The result? Disk contention that limits your database's scalability.

Why Separate WAL Files?

Moving WAL files to their own dedicated disk delivers several key benefits:

Performance Optimization: Sequential WAL writes can proceed uninterrupted by random data file I/O, improving write throughput.

Reduced I/O Contention: Your data disk and WAL disk work in parallel, eliminating competition for resources.

Storage Flexibility: You can place WAL files on specialized storage like high-durability SSDs optimized for sequential writes.

Enhanced Disaster Recovery: Physical separation means if your data disk fails, your WAL files remain intact on a separate disk, providing additional recovery options.

The Migration Process

Let me walk you through relocating your WAL files safely, without any downtime or data loss.

Step 1: Create Your New WAL Directory

First, create a dedicated directory on your target disk volume:

mkdir -p /u03/app/18/wal_files

This will be the new home for all your WAL files.

Step 2: Set Proper Ownership

Ensure the PostgreSQL user owns this directory:

chown -h postgres:postgres /u03/app/18/wal_files

PostgreSQL needs write permissions to store WAL files here, so proper ownership is crucial.

Step 3: Stop PostgreSQL

Before touching any critical files, gracefully shut down your PostgreSQL server:

./pg_ctl stop

This ensures no new WAL records are being written during the migration.

Step 4: Copy Existing WAL Files

Use rsync to transfer all existing WAL files to the new location:

rsync -av /u02/app/18/data/pg_wal/* /u03/app/18/wal_files

The -av flags preserve file attributes and provide verbose output so you can monitor the transfer progress.

Step 5: Verify the Transfer

Confirm everything copied successfully:

ls -la /u03/app/18/wal_files

Compare the file count and sizes with the original directory. Every WAL file should be present in the new location.

Step 6: Backup the Original Directory

As a safety measure, rename the original WAL directory:

mv /u02/app/18/data/pg_wal /u02/app/18/data/pg_wal-backup

This preserves your original files just in case something goes wrong. Better safe than sorry!

Step 7: Create a Symbolic Link

Now for the clever part. Create a symbolic link that points PostgreSQL to the new location:

sudo ln -s /u03/app/18/wal_files/ /u02/app/18/data/pg_wal

This symbolic link makes the change completely transparent to PostgreSQL. The database expects to find WAL files at /u02/app/18/data/pg_wal, and the symlink redirects those requests to your new location.

Step 8: Start PostgreSQL

Fire up your database server:

./pg_ctl start

PostgreSQL will follow the symbolic link and start writing WAL files to the new location.

Step 9: Verify Everything Works

Connect to your database and force a WAL switch to confirm the new setup is working:

psql -h localhost -U postgres -p 5432

Then run this SQL command:

SELECT pg_switch_wal();

Check your new WAL directory—you should see fresh WAL files appearing there.

Step 10: Clean Up

Once you've verified everything is running smoothly for a few days, you can safely remove the backup:

rm -rf /u02/app/18/data/pg_wal-backup

What Performance Gains Can You Expect?

After relocating WAL files to a dedicated disk, you'll typically see:

• Reduced I/O contention during heavy write operations
• More consistent transaction performance, especially under load
• Better overall throughput for mixed read/write workloads
• Improved recovery time if failures occur

For write-intensive applications, this optimization can make a noticeable difference in transaction throughput and response times.

Don't Forget to Monitor

After making this change, keep an eye on these metrics:

• WAL generation rate on the new volume
• I/O wait times on both data and WAL disks
• Overall transaction throughput
• Checkpoint performance and timing

This monitoring helps you quantify the performance improvement and catch any issues early.

Why the Symbolic Link Approach Works

One of the elegant aspects of this migration is that it requires zero configuration file changes. PostgreSQL doesn't need to know that WAL files have moved—the symbolic link handles everything transparently. This makes the process simpler and less error-prone than modifying configuration parameters.

Wrapping Up

Moving PostgreSQL WAL files to a dedicated disk is one of those optimizations that delivers significant bang for your buck. The process is straightforward, the risk is minimal (especially with proper backups), and the performance benefits are substantial.

This technique is particularly valuable for write-heavy workloads where WAL throughput can become a bottleneck. By eliminating I/O contention between WAL writes and data file operations, you're allowing your database to perform at its full potential.

Coming Up Next

In my next post, I'll cover relocating PostgreSQL temporary files to a dedicated volume—another powerful optimization technique that can dramatically improve query performance for operations involving large sorts and joins.

Have you relocated your WAL files? What performance improvements did you see? Share your experiences in the comments below!