Hacker News
points by jon128 4 days ago | 0 comments
Users of software often do not blindly do, or not do, whatever the upstream open source project does.

OrioleDB is friendlier to SSDs and is de facto "the other" MVCC of Postgres. OrioleDB may be still be "beta" but that hasn't stopped operators/users.

MariaDB has some alternative MVCC, one of them is particularly outstanding.

SSD endurance at scale has on and off been a major concern for me, so I empathize with that. Others deserve to know of OrioleDB, and Postgres more broadly is probably better off for it too.

  https://www.uber.com/us/en/blog/postgres-to-mysql-migration/
[–] hans_castorp 4 days ago
All of the problems Uber had, could have been solved back then, had they actually asked for help on the mailing list. Several of the issues they had have also been fixed/changed in Postgres itself as a reaction to that discussion.
[–] jon128 3 days ago
Please elaborate on details if you can.

What Uber posted there did prompt me to investigate the topic of Postgres old MVCC, OrioleDB, and MariaDB's alternative MVCC.

Ultimately, one change in a row results in the entire row being written again, from what I read. Is this not accurate?

MariaDB's MVCC doesn't write the entire row again, only the delta. One of the newer more advanced MVCC for MariaDB are even more efficient.

In my view, "runaway vacuum" has never not been a case of either poorly done IT operations or poorly thought out (or just not thought out) database usage patterns by the in-house application developers. While "throw hardware at the problem" isn't a great answer, I have never not seen NVDIMM for ZFS ZiL/SLOG not mitigate "runaway vacuum", as ugly as that is -- that was a long time ago though.

SSD endurance can get daunting in an advanced hosting environment. It's odd that I don't often see others have these metrics in their Prometheus+Grafana. The people who are telling me that OrioleDB alleviates their endurance concerns aren't at liberty to show me their Grafana.

I might be able to get some real SSD endurance metrics comparisons at meaningful scale over the next couple years but I don't know.

Beyond that, I think the only real way to find out is a snapshot of real-world application production Postgres databases and use logical replication to replay a year of database traffic to find out what the delta on SSD endurance impact is.

I don't claim to be a Postgres expert relative to the upper echelon that frequents this site, always happy to get more insight to Postgres, my attention has generally been on either North or South side of that part of a webscale stack.

[–] Sesse__ 4 days ago
It's also hard to even claim they migrated from “PostgreSQL” to “MySQL”; they surely run MySQL underneath in their new system, but it's a really weird hybrid where it's basically only the storage engine. Even secondary indexes, on of their main points of contention in the article, is managed as a separate system on top of the database.