Why a Mirror?

KoldStore already uses PostgreSQL WAL as its change source (logical decoding into a database worker). It still maintains a per-table latest-state mirror (koldstore.<table>__cl) because WAL and the mirror solve different problems.

WAL is an excellent change transport. The mirror is an operational data structure for flush, change feeds, and primary-key lookups.

Compare

Need	PostgreSQL WAL	Latest-state mirror (`__cl`)
Crash recovery / PITR / physical replica	Designed for this	Not its job
Decode every committed change	Native	Applied once by the worker
Latest state of one primary key	Replay + resolve	Indexed row (`WHERE id = …`)
Rows pending flush	Reconstruct from history	The table is the queue
Resume change feed from a cursor	Slot LSN + filter/replay	`WHERE seq > $last`
Per-table isolation	Shared stream; filter later	One `__cl` per managed table
Inspect / debug with SQL	Decoding tooling	Normal `SELECT`
Append-only history of every UPDATE	Yes	No — one row per PK

Latest state, not another WAL

Four WAL records for the same key become one mirror row:

TEXT

1WAL:    INSERT id=10 → UPDATE → UPDATE → DELETE2Mirror: id=10, op=DELETE, seq=8471294123

Flush and catch-up need “what is pending for this key now,” not a full rewrite of intermediate versions.

What the mirror makes cheap

SQL

1-- Pending flush batch2SELECT * FROM koldstore.messages__cl3ORDER BY seq LIMIT 1000;4 5-- Change-feed resume6SELECT * FROM koldstore.messages__cl7WHERE seq > 912341238ORDER BY seq;9 10-- Still hot before archive?11SELECT 1 FROM koldstore.messages__cl WHERE id = 10;

Those are ordinary indexed queries. Doing the same against raw WAL means decoding, replaying, visibility, and reconstructing latest state on every use.

Complementary, not competing

TEXT

1PostgreSQL WAL2      │3Logical decoding4      │5Materialize latest state6      │7Mirror (__cl)8      │9Flush + changes_since + hot/cold lifecycle

Today that path is already live: heap commit → WAL → applier → __cl. A future capture change would still target the same mirror and the same external APIs.

Summary

WAL moves durable changes through PostgreSQL.
Mirror materializes latest-per-PK state for flush queues, resume cursors, and PK lookups.
They are layers in one design, not alternatives.