←back to thread

Why does everyone run ancient Postgres versions?

(neon.tech)
264 points davidgomes | 4 comments | 17 Oct 24 21:23 UTC | HN request time: 0.858s | 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 #
api ◴[18 Oct 24 00:10 UTC] No.41875126[source]▶
I've always wondered why Postgres is so insanely popular. I mean it has some nice things like very powerful support for a very comprehensive subset of SQL functionality, but most apps don't need all that.

It really feels like early 1990s vintage Unix software. It's clunky and arcane and it's hard to feel confident doing anything complex with it.

replies(9): >>41875168 #>>41875240 #>>41875306 #>>41875587 #>>41876346 #>>41876770 #>>41877119 #>>41877951 #>>41878394 #
tpmoney ◴[18 Oct 24 00:42 UTC] No.41875306[source]▶
> I've always wondered why Postgres is so insanely popular.

In no particular order, my preference for postgres is driven by:

  * Date / time functions that don't suck
  * UTF-8 is really UTF-8
  * 99% of a backup can be done live with nothing more than rsyncing the data directory and the WAL files
  * Really comprehensive documentation
  * LTREE and fuzzy string match extensions
  * Familiarity from using it for years
MySQL/Maria I'm sure is fine, but it's one of hose things where it's just different enough and I haven't encountered a compelling use case for changing my preference.
replies(3): >>41875336 #>>41876296 #>>41879736 #
1. sgarland ◴[18 Oct 24 04:16 UTC] No.41876296[source]▶
MySQL does have ON UPDATE for its DATETIME, though; something that Postgres inexplicably still lacks.
replies(1): >>41877969 #
2. fanf2 ◴[18 Oct 24 10:24 UTC] No.41877969[source]▶
Isn’t ON UPDATE related to foreign keys and independent of the data type? https://www.postgresql.org/docs/current/ddl-constraints.html...
replies(1): >>41878336 #
3. paulryanrogers ◴[18 Oct 24 11:22 UTC] No.41878336[source]▶
Maybe they're thinking of TIMESTAMP in MySQL, which IIRC would auto update its value on any update to the row. Which was useful for uodated_at like columns. Though I think they later limited it to only the first TIMESTAMP column in a table.
replies(1): >>41878876 #
4. sgarland ◴[18 Oct 24 12:41 UTC] No.41878876{3}[source]▶
No, it works for both [0] types. The first TIMESTAMP thing you’re referring to is that if a specific variable isn’t set, the first TIMESTAMP column automatically gets auto updates applied on creation and update, unless you explicitly defined it to not. This was the default behavior in 5.7, but has since been changed.

[0]: https://dev.mysql.com/doc/refman/8.0/en/timestamp-initializa...