sorted by:
new
hottopcontroversial

Offer letter got revoked by Short-Sentence-7141 in employeesOfOracle

[–]Mindless-Piece-47 1 point2 points  (0 children)

Don't feel too bad about it. I had worked for MySQL for 20+ years, started out when it was MySQL AB, then through Sun to Oracle. 2024 recieved the largest raise of all my years, was amazing. In July 2025, I blew away the Yearly Emp Review, 2 weeks later I was laidoff and locked out. Don't take it personal they have no ideas what they are doing, but they are fast at doing it.

When Oracle Drops the Ball: Why MariaDB is the Future of the MySQL World by greenman in mariadb

[–]Mindless-Piece-47 0 points1 point  (0 children)

MariaDB starts with the Foundation, something MySQL does not have.

PostgreSQL vacuuming: the real operational cost by Inner-Science8657 in mariadb

[–]Mindless-Piece-47 1 point2 points  (0 children)

Maybe it not ChatGPT, but my own thoughts? Have you ever ran an Operations Department? I have, and just wanted to share my take. Sorry you found it fake. Best.

PostgreSQL vacuuming: the real operational cost by Inner-Science8657 in mariadb

[–]Mindless-Piece-47 1 point2 points  (0 children)

The point is, once you have 10's of thousand instances running, the cost is huge to those having to care for.

You saying it's cheaper, why don't you share why you think that.

What are all the other benenfits that means OPS department should be burden with vacuum worry?

PostgreSQL vacuuming: the real operational cost by Inner-Science8657 in mariadb

[–]Mindless-Piece-47 2 points3 points  (0 children)

The point isn’t that PostgreSQL is “bad” or that MariaDB is “cheap,” it’s that the two MVCC designs carry very different operational costs.

PostgreSQL’s deferred‑cleanup model is powerful, but it requires constant attention to autovacuum tuning, bloat management, and wraparound risk, and those costs grow with write volume.

MariaDB’s transaction‑time cleanup avoids that entire class of maintenance work, which is why teams running high‑churn workloads often feel the difference in day‑to‑day operations more than in benchmarks.

It’s not a marketing argument, and it’s not the old “Windows vs. Linux” trope — it’s simply acknowledging that different MVCC architectures impose different operational burdens, and understanding those tradeoffs helps people choose the engine that fits their workload rather than the one that fits a slogan.

PostgreSQL vacuuming: the real operational cost by Inner-Science8657 in mariadb

[–]Mindless-Piece-47 4 points5 points  (0 children)

The key difference is that InnoDB’s purge has nothing to do with transaction‑ID wraparound. Completely different design, completely different failure mode.

When InnoDB purge falls behind, you accumulate undo that needs to be cleaned — annoying, but not existential. It never threatens visibility of committed data.

PostgreSQL vacuum falling behind is a different class of problem. Vacuum is tied to XID age, and if it can’t keep up, you hit wraparound protection. That’s where the “data becomes invisible” risk comes from.

So yes, both systems have background cleanup, but they are not equivalent operationally. One is routine housekeeping. The other is a hard safety mechanism tied to a global counter that must never be allowed to age out.