Multiplatform Reality Checks: pg_stat_wal vs. Oracle Redo Metrics

For anyone who has spent years tuning Oracle redo, the first time you look at PostgreSQL’s pg_stat_wal view may feel a bit underwhelming. Everything works, but the instrumentation isn’t the same and you suddenly realize how much Oracle has spoiled you with it’s advanced and expensive features.

As I’ve been working deeper with PostgreSQL, I keep getting questions about how its WAL (Write-Ahead Logging) data compares to Oracle’s redo performance metrics. Let’s break it down in a way that makes sense for people who’ve been living in the Oracle world for years.

PostgreSQL and What pg_stat_wal Actually Gives You

PostgreSQL introduced pg_stat_wal relatively recently, and it provides solid but high-level visibility into WAL activity. You’ll see metrics like:

• Total WAL bytes written
• Rate of WAL generation
• Full-page-write counts
• Number of writes and number of fsyncs
• Estimated sync times

This is great for understanding the following:

• How “chatty” the system is
• When a workload causes WAL spikes
• Whether storage performance is keeping up
• How to scale archive and replica throughput

It’s not like we’re going to confuse it with the deep dive Oracle veterans are used to. pg_stat_wal gives you throughput and timing, not internal behavior.

There’s no visibility into:

• Contention for internal WAL structures
• Per-session redo production
• Per-wait-event breakdowns
• Background writer pressure
• Commit latency causality
• Checkpoint-induced stall details

It’s helpful, but it’s nowhere near the comprehensive instrumentation that Oracle spent decades building.

Oracle Redo Has Decades of Instrumentation and It Shows

Oracle’s redo logging system is one of the most heavily instrumented parts of the database engine. An Oracle DBA with years under their belt, knows many of these views inside and out:

• V$LOG, V$LOGFILE, V$LOG_HISTORY
• V$SYSSTAT, V$SESSTAT, V$MYSTAT
• V$SYSTEM_EVENT, V$SESSION_EVENT
• V$EVENT_HISTOGRAM
• V$LATCH for redo copy and redo allocation
• V$ARCHIVE_DEST for archiver throughput

*The above views are not part of the Automatic Workload Repository (AWR) and are not part of a management pack, but still part of the standard and enterprise edition license.

An example of a query that may look at waits on redo log switches might look like the following:

WITH log_window AS (
    -- Focus on the last 30 minutes of log switches
    SELECT MIN(first_time) AS start_time,
           MAX(first_time) AS end_time
    FROM   v$log_history
    WHERE  first_time >= SYSDATE - INTERVAL '30' MINUTE
),
sess_redo AS (
    -- Per-session redo stats
    SELECT st.sid,
           MAX(CASE WHEN sn.name = 'redo size'    THEN st.value END) AS redo_size_bytes,
           MAX(CASE WHEN sn.name = 'redo entries' THEN st.value END) AS redo_entries
    FROM   v$sesstat  st
    JOIN   v$statname sn
           ON sn.statistic# = st.statistic#
    WHERE  sn.name IN ('redo size','redo entries')
    GROUP BY st.sid
),
sess_waits AS (
    -- Sessions waiting on log-switch-related events
    SELECT se.sid,
           se.event,
           se.total_waits,
           se.time_waited_micro
    FROM   v$session_event se
    WHERE  se.event IN (
             'log file switch (archive incomplete)',
             'log file switch (checkpoint incomplete)',
             'log file switch completion'
           )
)
SELECT lh.thread#,
       lh.sequence#,
       lh.first_time,
       sw.sid,
       sw.event,
       sw.total_waits,
       ROUND(sw.time_waited_micro / 1e6, 3) AS time_waited_sec,
       ROUND(sr.redo_size_bytes / 1024 / 1024, 1) AS redo_mb,
       sr.redo_entries
FROM   v$log_history lh
       CROSS JOIN log_window lw
       JOIN   sess_waits sw
              ON lh.first_time BETWEEN lw.start_time AND lw.end_time
       JOIN   sess_redo  sr
              ON sr.sid = sw.sid
WHERE  lh.first_time BETWEEN lw.start_time AND lw.end_time
ORDER BY lh.first_time,
         time_waited_sec DESC
/

Yes, the query is a little more involved and an output example might look like this:

THREAD#	SEQUENCE#	FIRST_TIME	SID	EVENT	TOTAL_WAITS	TIME_WAITED_SEC	REDO_MB	REDO_ENTRIES
1	18234	25-NOV-25 10:02:11	321	log file switch (checkpoint incomplete)	42	18.247	512.3	1245890
1	18234	25-NOV-25 10:02:11	417	log file switch (archive incomplete)	15	6.931	305.7	845221
1	18234	25-NOV-25 10:02:11	512	log file switch completion	11	3.404	92.4	201887

 

Oracle exposes things PostgreSQL simply doesn’t track:

• LGWR wait events and detailed IO timings
• Redo buffer contention (allocation/copy latch pressure)
• Why commits stall (latch, IO, CPU, archive lag, wakeups)
• Per-session redo generation
• Archiver/standby delays at per-destination granularity

And of course, the wait-event model gives you the kind of nuanced insight that Oracle DBAs take for granted:

“Is the commit slow because of IO, CPU, log buffer space, archiver pressure, or LGWR scheduling?”

PostgreSQL can tell you that commits slowed down. Oracle can tell you the why, and precisely where the hurt is happening.

Side-by-Side Comparison

WAL/Redo Data Exposure

Capability	PostgreSQL (pg_stat_wal)	Oracle Redo Metrics
WAL/redo bytes generated	Yes	Yes
Number of writes/syncs	Yes	Yes
Full-page-write counts	Yes	N/A
Commit latency details	Very limited	Deep and granular
Redo buffer contention	Not exposed	Fully exposed
Process-level waits	None	Extensive LGWR / latch waits
Log switch history	Limited	Rich historical tracking
Archiver performance	Basic	Detailed per destination
Per-session redo stats	No	Yes
Tuning depth	Basic	Advanced

Why the Gap Exists: Different Architectures, Different Priorities

I really want to add, the contrast isn’t because one database is “better;” it’s because the logging pipelines are designed differently and the investment is over decades for Oracle.

PostgreSQL WAL Architecture

• Group commit model
• Background WAL writer, background checkpointer
• No single LGWR process
• Lighter, simpler write pipeline
• Less risk of centralized contention

Oracle Redo Architecture

• Central LGWR process
• Separate log buffer
• Redo allocation/copy latches
• Highly tuned for extreme OLTP workloads
• Three decades of instrumentation

Oracle essentially built a redo subsystem that’s self-diagnosing. PostgreSQL’s is efficient and resilient, but not nearly as chatty.  This has significant positives and negatives for both, but it’s important to understand what those are.

So What Does This Mean for multiplatform DBAs?

If you’re coming from Oracle, here’s the honest truth:

pg_stat_wal will feel sparse, and sometimes frustrating.

You can still tune PostgreSQL WAL effectively, but you will just rely more on inference than on the kind of hard wait event data Oracle hands you on a silver platter.

In PostgreSQL, you’ll focus more on:

• Checkpoint behavior
• WAL file recycling
• fsync timing
• Storage throughput
• Replica lag
• Workload patterns

And you’ll use pg_stat_wal as one piece of the picture—not a complete story.

In Summary

Both databases have robust, reliable logging systems. Oracle’s redo visibility is legendary and unmatched. PostgreSQL is getting better every release, but WAL instrumentation today is still a “just enough” model compared to Oracle’s “instrument everything” philosophy.

For Oracle DBAs crossing over, the key is adapting to the PostgreSQL mindset.  You don’t get all the internals, but you do get enough to guide you, and the rest comes from understanding the system more intuitively under the covers.