←back to thread

264 points davidgomes | 1 comments | | HN request time: 0.36s | source
Show context
paulryanrogers ◴[] No.41875055[source]
Upgrades are hard. There was no replication in the before times. The original block-level replication didn't work among different major versions. Slony was a painful workaround based on triggers that amplified writes.

Newer PostgreSQL versions are better. Yet still not quite as robust or easy as MySQL.

At a certain scale even MySQL upgrades can be painful. At least when you cannot spare more than a few minutes of downtime.

replies(7): >>41875126 #>>41876174 #>>41876232 #>>41876375 #>>41877029 #>>41877268 #>>41877959 #
slotrans ◴[] No.41876232[source]
"Not as robust as MySQL"? Surely you're joking.
replies(3): >>41876309 #>>41876384 #>>41877139 #
sgarland ◴[] No.41876309[source]
They’re not wrong. If you’ve ever spent meaningful time administering both, you’ll know that Postgres takes far more hands-on work to keep it going.

To be clear, I like both. Postgres has a lot more features, and is far more extensible. But there’s no getting around the fact that its MVCC implementation means that at scale, you have to worry about things that simply do not exist for MySQL: vacuuming, txid wraparound, etc.

replies(3): >>41876387 #>>41876650 #>>41877061 #
wbl ◴[] No.41876387[source]
Yeah but you don't need to worry about your data existing. MySQL has been known to silently fail the one job of a DB.
replies(2): >>41876576 #>>41876737 #
SavageBeast ◴[] No.41876576[source]
I recall this being the case A LOOOONG time ago but I haven't heard of, read about, been warned to look out for or personally seen such a thing in forever. Have you?

* I'm running a lot of MySQL stuff and such a topic might be of interest to me

replies(2): >>41876711 #>>41876762 #
o11c ◴[] No.41876711[source]
From what I can tell, MySQL is supposed to be safe since 2018 if you have no data from before 2010.

The fact that you still can't use DDL in transactions makes life exceedingly painful, but it's technically safe if you write your migration code carefully enough.

replies(2): >>41876795 #>>41877299 #
p_l ◴[] No.41877299[source]
Some places still have columns declared as utf8 instead of utf8mb4, and there's a special place in hell for authors of the MySQL general clusterfuck regarding encodings - it was all nice and great if you didn't care about anything other than latin1 or ASCII - go outside that before utf8 option and it was horror that even experienced operators managed to fuckup (I have a badge from a Google conference in 2017 with nicely visible effect of "we have mixed up one of the three separate encoding settings in MySQL and now you have mojibake in your badge").

And then there's UTF8 not actually being UTF8, which can result in total lockup of a table if someone inputs a character that does not fit in UCS-2 and now you need to recover the database from backup and preferably convert all instances of utf8 to utf8mb4, because fuck you that's why.

replies(1): >>41878454 #
lol768 ◴[] No.41878454[source]
Yeah, the whole charset/collation design is a complete dumpster fire.
replies(1): >>41878747 #
1. sgarland ◴[] No.41878747[source]
In fairness, reasoning about collations is like peering into the abyss. I get why they’re required to have so many levels of detail, and the Unicode Consortium has done a fantastic job, but to say they’re complicated is putting it mildly.