Seconded. Coming from MySQL this is a huge regression that makes Postgres look like something from the 80s. I still wonder why this isn't seen as the absolutely highest priority.

▲

jeltz 4 hours ago | parent | next [-]

I have not ran MySQL for some years but it at least used to have exactly the same issue. Upgrading a database with MySQL can take a long time if you have many tables. The main difference is only really that PostgreSQL does it with a separate tool, pg_upgrade, while MySQL does it as part of the main binary.

For both MySQL and PostgreSQL you will need to use some kind of logical upgrades if you want no downtime.

▲

boxed 3 hours ago | parent | next [-]

They don't change the on-disk structure all the time though...

	▲	jeltz 13 minutes ago \| parent [-]
		Mostly because MySQL development is slower.

▲

tomnipotent 4 hours ago | parent | prev [-]

MySQL has advocated for decades spinning up a replica with the upgraded version, waiting for it to catch up to master before promoting it to the new master. You can do the same thing with Postgres.

	▲	jeltz 3 hours ago \| parent [-]
		Exactly, MySQL and PostgreSQL are the same here. Maybe one is a bit faster than the other at doing major version upgrades but the behaviours are quite similar.

▲

Blackthorn 4 hours ago | parent | prev [-]

Probably because it's an open source project and apparently none of its users cared about this feature enough to develop it or fund it.

	▲	jeltz 3 hours ago \| parent \| next [-]
		It is also a bit tricky tradeoff. You do not want to be stuck with the same data format forever. So databases like MySQL and PostgreSQL need a downtime when doing a major version upgrade. They both try to keep it short, usually seconds, but minutes can happen in either database.
	▲	4 hours ago \| parent \| prev [-]
		[deleted]