There was a time when PostgreSQL’s own developers were far more open about the real cost of their MVCC design. Back in the 8.1 era, the documentation spelled out the resource drain, the vacuum overhead, and the “cold comfort” of wraparound risk in plain language. I first read that line in 2003, and it stuck with me for more than twenty years. I could not imagine any serious operations team wanting a database that required a separate background process to clean up transactions long after they had completed. PostgreSQL has absolutely improved vacuuming — autovacuum, visibility maps, HOT updates, parallel vacuum, better defaults, better alerts. But all of these are optimizations around the same architecture. PostgreSQL still creates dead rows that must be cleaned up later, and that deferred cleanup is the root of vacuum lag and wraparound risk.
The architecture hasn’t changed, and that’s the part that matters from an operations perspective.
Reference:
https://www.postgresql.org/docs/8.1/maintenance.html
1. The Cost of VacuumingVacuuming exists because PostgreSQL’s MVCC design leaves behind dead row versions that must be cleaned up later. PostgreSQL has made that cleanup less painful over the years, but it has not made it free, and it has not made it predictable.
Vacuuming still consumes CPU, I/O, memory bandwidth, and time.
It still competes with production workloads.It still must be tuned.
It still must be monitored.
It still must be understood.
When the autovacuum falls behind, performance degrades.
When it stalls, wraparound risk becomes real.
When it cannot keep up with workload churn, administrators must intervene manually.
This is not a theoretical cost. It is a constant operational burden.
2. Why Wraparound Is Still a Real Operational RiskThe older documentation was brutally honest: if the transaction ID counter wraps, the database enters a state where older rows appear to be “in the future” and become invisible. The data is still present, but inaccessible. That is the “cold comfort” line that stuck with so many of us.
Modern PostgreSQL has safeguards, autovacuum, and warnings, but the fundamental risk remains. Every PostgreSQL cluster is on a countdown timer from the moment it starts accepting transactions. If vacuuming cannot keep up — due to load, misconfiguration, or resource starvation — wraparound becomes a real threat.
This is not a failure mode you see in engines that clean up at transaction time.
3. How PostgreSQL’s Messaging Changed Over Time
The shift in documentation tone matters. In the early days, PostgreSQL’s docs were written by engineers who wanted administrators to understand the full cost of the MVCC model. They did not hide the risks. They did not soften the language. They did not pretend vacuuming was free.Today, the documentation is more polished and less direct. The mechanisms are the same. The risks are the same. The operational burden is the same. What changed is the messaging.
Teams making architectural decisions deserve clarity, not softened language.
4. MariaDB: Transaction‑Time Cleanup and Lower Operational StressMariaDB (and MySQL‑family engines) avoid this entire class of problems by cleaning up row versions at transaction time. There is no background janitor. No vacuum lag. No wraparound timer. No need to tune autovacuum workers or throttle I/O to keep the system responsive.
For operations teams, this difference is enormous:
• fewer moving parts• fewer failure modes
• no existential wraparound risk
• no CPU or I/O spikes from cleanup
• no vacuum queues to monitor
• no vacuum tuning parameters to babysit
When you are running real systems with real deadlines, distractions like vacuuming take attention away from the work that actually moves the business forward.
MariaDB’s design reduces operational stress because it eliminates an entire category of maintenance that PostgreSQL must perform just to stay healthy.
ConclusionVacuuming is not a footnote. It is not a minor detail. It is a core architectural cost of PostgreSQL’s MVCC model, and it has real consequences for systems and operations teams. PostgreSQL has improved vacuuming, but the fundamentals — deferred cleanup, vacuum lag, and wraparound risk — remain unchanged.
If you are choosing an MVCC engine for real operational workloads, you need to understand the cost — not just in CPU and I/O, but in operational focus, staffing, and risk.MariaDB avoids this entire class of problems by cleaning up at transaction time. That difference still matters.
In operations, the cost you ignore is the cost that bites you. MariaDB removes an entire category of pain before it ever reaches your team.
Author
Jonathan (Jeb) Miller
Benchmarking Enablement Facilitator, MariaDB Foundation
Jonathan brings more than two decades of deep operational and database performance experience across state‑level systems and major database vendors. Before joining the MariaDB Foundation, he spent over 20 years at Oracle MySQL as a Senior Principal Software Quality Assurance Automation Developer, specializing in performance testing, benchmarking, and automated validation. Prior to that, he served as a Senior Quality Engineer at Pervasive Software and taught software qa courses at Austin Community College for more than a decade.
His operational background includes leading mission‑critical statewide systems for Texas EBT, Texas Hunting and Fishing Licensing, and the Texas Failure to Appear program, where he managed 24×7 hardware, OS, and database operations across Sybase, MSSQL, and large‑scale transactional workloads. This combination of real‑world operations and deep database performance engineering informs his work on open, reproducible benchmarking frameworks for the MariaDB ecosystem.