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.

My upgrade policy for everything:

Significant security vulnerability? Upgrade

Feature you need? Upgrade

All other reasons: Don't upgrade.

Upgrading takes effort and it is risky. The benefits must be worth the risks.

Related...

  postgres    1958  0.0  0.0 247616 26040 ?        S    Jul21   3:03 /usr/lib/postgresql/11/bin/postgres
  postgres 1085195  0.0  0.0 249804 24740 ?        Ss   Aug19   2:01 /usr/lib/postgresql/13/bin/postgres
  postgres 1085196  0.0  0.0 223240 27900 ?        Ss   Aug19   1:59 /usr/lib/postgresql/15/bin/postgres

Postgres is the only thing on my Debian that doesn't seamlessly automatically upgrade across dist-upgrades, but instead leaves old versions around for me to deal with manually... which I seem to never get around to.

The risk/reward ratio of fucking with something that works perfectly fine as is is not great.

So for fresh installs yes but existing ones not so much

Databases tend to be "stickier" than other parts of any large software system. Largely because database migrations are costly. You can't just tear down an old database and rebuild a new one, you have to figure out how to move all that data across too.

The consequence is that things in database-land tends to move slower than other types of software. This I think is the major reason why we still use SQL.

In Oracle, ALTER TABLE MOVE in 8i was a godsend, finally enabling a table reorganization without export/import.

My timid management forbade an upgrade from Oracle 7.3.4 until 2013. It was agony to remain on that museum piece for as long as we did.

I am upgrade-minded, but my management is not. I always lose.

I am retiring in two years. I will not miss their problems, not at all.

Edit: Oracle 10g was the last release that (for us) brought must-have features. Sure, upgrading to 19 or 23 would be great, but it doesn't bring anything that I really want.

I have a large production deployment that is still on 9.6 because the software depends on table inheritance. (Oh man!)

If PostgreSQL has replication, why are they talking about "minimal" downtime? Is there no quorum strategy that delivers high availability? I don't know as much as I should.

Because upgrading is a lot of work, and is higher risk than upgrading other software.

I've always found it fascinating that there is a vocal contingent at HN that seems to legitimately hate advertising. But then an article like this turns up that is obvious advertising and is also a good article - we get a nice summary of what the major performance features over different postgres versions are, and some interesting case studies (I'd never even heard of the NOT VALID option although apparently it is nothing new).

Honestly, I've aside from React and Java (8 -> 21 is big but still not that big), there's very little software that I updated and noticed a major step change difference in the system. Once it works, its fine

Weird that the maybe-AI-generated image of a column says "Postgres 13" on it when the article talks about Postgres 17.

> Postgres 17.0 has been out for a bit and ...

No. It's been released in September 2024. That's not "quite a bit".

Now as to why people aren't all on 17 and not even on 16 yet, here's an acronym for you: LTS [1]

Debian 11 Bullseye is the current LTS. It came out in 2021.

[1] https://en.wikipedia.org/wiki/Long-term_support