The Undo Log Storage PostgreSQL Doesn't Have (Yet)

Table bloat and VACUUM struggles are among the most common operational pains in PostgreSQL. They are a direct consequence of how PostgreSQL's MVCC implementation handles updates and deletes: every change appends a new row version. Although VACUUM is designed to handle this, sometimes it can't keep up, because of long-running transactions, high write throughput, or its own scheduling limits. That causes tables and indexes grow far beyond the size of the actual data they hold, and query performance degrades. Many other databases use an undo-log storage MVCC implementation instead of an append-only heap. With that approach, old row versions move into a separate, size-limited log rather than staying in the table. PostgreSQL has tried to adopt this approach more than once and it still hasn't landed upstream. This talk tells that story step by step: what table bloat actually is and why VACUUM sometimes can't keep up. Why PostgreSQL's append-only MVCC design is the structural root cause and not just a tuning problem. What undo-log storage is, how it may help and what it costs in return, including how a now-removed PostgreSQL feature (old_snapshot_threshold) already demonstrated a tradeoff. And finally, where the idea stands today through active projects like OrioleDB. By the end of this session, attendees will be able to: - explain what table bloat is and why VACUUM doesn't always solve it; - explain why table bloat happens at the MVCC level, not just as an operational symptom; - describe what undo-log storage is, how it addresses bloat, and what tradeoffs it introduces; - understand the current state of undo-log storage in PostgreSQL (zheap, OrioleDB). Audience: Beginners and intermediate PostgreSQL users. Basic familiarity with SQL and transactions is enough.