Changelog
SQL Server transaction-log CDC reads compressed backups and compressed tables
Artie's transaction-log method now reads log backups taken WITH COMPRESSION, decodes ROW- and PAGE-compressed tables, and publishes each transaction only after it commits.
Artie's transaction-log method for SQL Server reads changes from your .trn log backups instead of the live database. Three things got in its way. Backups taken WITH COMPRESSION, or on a server whose backup compression default is on, could not be read at all. Tables using ROW or PAGE compression failed to decode. And because changes were published in log order, a transaction that later rolled back could reach the destination before the records that undid it.
Reader now reads compressed log backups transparently, in both the default MS_XPRESS format and the ZSTD format SQL Server 2025 added, and decodes rows from ROW- and PAGE-compressed partitions like any other table. Columnstore compression and QAT_DEFLATE backups are rejected with a clear error rather than skipped. Reader also publishes a transaction only once it commits, whole and in commit order, so a transaction that rolls back never reaches your destination. Transactions that stay open across several log backups are held until they commit, spilling to disk past 4 MB per transaction so a long-running one does not pile up in memory.
Two performance changes landed alongside. Records from the same log block now share one copy of it, which cut Reader's memory for this method from roughly 270 times the backup size to about 6 times. And large transactions publish in batches of about a thousand messages instead of roughly 30 records a second, so a multi-hundred-thousand-row update no longer takes hours to leave Reader.
This is for SQL Server teams using transaction-log CDC, especially ones with backup compression on by default or compressed tables.
Why this matters
- Keep your existing compressed backup schedule; nothing changes in how you take log backups
- Replicate
ROW- andPAGE-compressed tables with the same setup as everything else - Downstream never sees a change from a transaction that rolled back
- Large backups and long transactions no longer put Reader at risk of running out of memory