Live data from Hacker News

Why does everyone run ancient Postgres versions?

neon.tech

101–110 of 452 posts

Re: Why does everyone run ancient Postgres versions?

#101
post #82

Earlier quoted context omitted.

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,…

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.

Not in around 15 years. You're thinking of when MyISAM was the default storage engine for MySQL. It has been InnoDB for over a decade. InnoDB is very reliable - I've never had a single data loss incident in all that time, and I've managed some very large (PB-scale) and active databases.

Postgres is definitely more difficult to administer.

Re: Why does everyone run ancient Postgres versions?

#102
i ll tell you why from my end. I installed Postgres14 via homebrew many years ago on my Apple M1 mac mini. I searched a lot on how to "upgrade" this installation but found nothing. I have a few databases running with data on it which I can't afford to lose if something goes down for more than 1 hour. I wish someone would guide me on how to actually install a newer postgres such as v17 without breaking an existing v14 install or losing data since I am not an expert by any means

Re: Why does everyone run ancient Postgres versions?

#103
post #82

Earlier quoted context omitted.

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.

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

Yes, it is messy when you want your MySQL databases to be mission critical in production, e.g. handling a large amount of customer data. Historically MySQL's High Availability architecture has a lot of design and implementation issues because it was an afterthought. Dealing with large amount of critical data means you need it to be performant, reliable and available at the same time, which is hard and requires you to deal with caching, sharding, replication, network issues, zone/resource planning, failovers, leader elections and semi-sync bugs, corrupted logs, manually fixing bad queries that killed the database, data migration, version upgrades, etc. There is a reason why big corps like Google/Meta has dedicated teams of experts (like people who actually wrote the HA features) to maintain their mission critical MySQL deployments.

Re: Why does everyone run ancient Postgres versions?

#104
post #9

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 dow…

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.

> I've always wondered why Postgres is so insanely popular

Real answer: no licensing cost

Re: Why does everyone run ancient Postgres versions?

#105

i ll tell you why from my end. I installed Postgres14 via homebrew many years ago on my Apple M1 mac mini. I searched a lot on how to "upgrade" this installation but found nothing. I have a few databases running with data on it which I can't afford to lose if something goes down for more than 1 hour. I wish someone would guide me on how to actually install a newer postgres such as v17 without breaking an existing v14…

And this, kids, is a good example of why homebrew is not a real package manager, and why macOS is not the best at running production services.

I hope you have a backup somewhere else, not on the Mac Mini. One option would be to restore it on another machine on Postgres 14, follow the upgrade path to 17 (idk if you can jump directly but a few Google searches will cover this), verify the data, back up the new db, somehow upgrade Posgtres on your Mac, and restore the new back up. Done.

Re: Why does everyone run ancient Postgres versions?

#106

i ll tell you why from my end. I installed Postgres14 via homebrew many years ago on my Apple M1 mac mini. I searched a lot on how to "upgrade" this installation but found nothing. I have a few databases running with data on it which I can't afford to lose if something goes down for more than 1 hour. I wish someone would guide me on how to actually install a newer postgres such as v17 without breaking an existing v14…

Forget about something as major as Postgres, I have trouble updating packages (that aren't install via pip/npm/cargo) on Linux all the time as a newbie. The experience is worse than Windows for some reason.

Hell, I have a hard time to tell the version of some system build-in binaries.

A few months ago, I have trouble to unzip a file which turns out ot be AES-encrypted. Some answers on SO [1] saying I should update my `unzip` to newer version but I can't find any updates for my distro, and I have no idea (still no, so feel free to teach me) to update it manually to make my `unzip` supporting AES. And all the versions, the good and the bad, all say they're "version 6.0.0" despite they behavior obviously differently.

[1] https://stackoverflow.com/questions/60674080/how-to-open-win...

Re: Why does everyone run ancient Postgres versions?

#107

Earlier quoted context omitted.

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,…

My experience of both is that MySQL is easier for developers, PostgreSQL is easier for sysads. That was true in 2012; dunno if it still applies though.

I doubt it was true in 2012, because sysadmins would be the ones trying to make it run reliably, including things like replication, upgrades, etc.

Pretty sure that even in 2012 MySQL had very easy to use replication, which Postgres didn't have well into the late 2010s (does it today? It's been a while since I've ran any databases).

Re: Why does everyone run ancient Postgres versions?

#108
post #100

Earlier quoted context omitted.

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

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.

Lack of transactional DDL is certainly painful, but not unique for MySQL. Oracle doesn't support it either.

Re: Why does everyone run ancient Postgres versions?

#109
post #107

Earlier quoted context omitted.

My experience of both is that MySQL is easier for developers, PostgreSQL is easier for sysads. That was true in 2012; dunno if it still applies though.

I doubt it was true in 2012, because sysadmins would be the ones trying to make it run reliably, including things like replication, upgrades, etc. Pretty sure that even in 2012 MySQL had very easy to use replication, which Postgres didn't have well into the late 2010s (does it today? It's been a while since I've ran any databases).

> I doubt it was true in 2012, because sysadmins would be the ones trying to make it run reliably, including things like replication, upgrades, etc.

Possibly I got it wrong and switched around which was easier on the devs and which was easier on the sysads?

In my defence, ISTR, when talking to sysads about MySQL vs PostgreSQL, they preferred the latter due to having less to worry about once deployed (MySQL would apparently magically lose data sometimes).

Re: Why does everyone run ancient Postgres versions?

#110
Lots of dogmatism in this discussion, it seems. A couple of things:

1. Most psql deployments are not exposed to the interwebz, they are typically only accessible to the applications that need them by virtue of network setup (firewalls etc). This limits the attack vector to whatever the application does. Good.

2. Distro vendors (RHEL et al) often stick to major psql release for the lifecycle of the OS version. If the OS lives longer than the psql major version, they take on the responsability of backporting critical security issues.

3. While upgrades aren't hard, they're not easy either.

4. Psql is pretty much feature complete for many workloads, and pretty stable in general. For many people, there is little need to chase the latest major version.

Post reply on HN