[enz]

> MariaDB (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.

The article seems a bit misleading. AFAIK, MariaDB (InnoDB) have to "vacuum" too. The implementation details are different between InnoDB and PostgreSQL, and maybe the InnoDB's Undo Log approach is less subject to bloat and maintenance cost, but it still exist as the InnoDB Purge Thread: https://mariadb.com/docs/server/server-usage/storage-engines...

[jebmiller]

You’re right that every engine has some form of cleanup — that’s unavoidable. But this blog isn’t comparing internal MVCC mechanics or claiming that MariaDB has zero background activity. It’s not a technical deep dive at all. It’s written from the perspective of someone who has overseen operations at scale, and from that vantage point the distinction that matters is when cleanup happens and who carries the operational burden.

MariaDB’s transaction‑time cleanup doesn’t create the same operational surface area that PostgreSQL’s deferred cleanup does. There’s no vacuum lag, no wraparound risk, no autovacuum tuning, and no fleet‑wide SOPs for when cleanup falls behind.

That’s the cost I’m talking about — the cost that lands on ops teams when you’re running hundreds or thousands of instances.

So yes, every engine has cleanup. But only one model turns that cleanup into a recurring operational responsibility that scales with fleet size. That’s the entire point of the article.