←back to thread

Why does everyone run ancient Postgres versions?

(neon.tech)
264 points davidgomes | 1 comments | 17 Oct 24 21:23 UTC | HN request time: 0.22s | source
Show context
paulryanrogers ◴[17 Oct 24 23:59 UTC] 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 ◴[18 Oct 24 04:00 UTC] No.41876232[source]▶
"Not as robust as MySQL"? Surely you're joking.
replies(3): >>41876309 #>>41876384 #>>41877139 #
sgarland ◴[18 Oct 24 04:20 UTC] 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 ◴[18 Oct 24 04:39 UTC] 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 ◴[18 Oct 24 05:28 UTC] 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 ◴[18 Oct 24 06:01 UTC] 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 #
The_Colonel ◴[18 Oct 24 06:21 UTC] No.41876795[source]▶
Lack of transactional DDL is certainly painful, but not unique for MySQL. Oracle doesn't support it either.
replies(2): >>41879094 #>>41887918 #
tpmoney ◴[19 Oct 24 14:22 UTC] No.41887918[source]▶
Oracle also didn't support Boolean data types for a long time, and had a 20 some odd year public thread arguing that no one needed a Boolean data type (https://asktom.oracle.com/ords/f?p=100:11:0::::P11_QUESTION_...). They finally added it in Oracle 23 which is nice, but I wouldn't consider it to be in good company to be lacking something Oracle also lacks.
replies(1): >>41889141 #
1. The_Colonel ◴[19 Oct 24 17:27 UTC] No.41889141[source]▶
Not having a boolean data type is IMHO just an annoyance, not comparable to the lack of transactional DDL.

But to the point, people often use this point to claim that MySQL is a toy database, not usable for real world production use. I use Oracle as a counterpoint, which also has a lot of warts but is pretty much an archetype of an enterprise-grade DB engine.