alt Hacker NewsBroadly for Pg, minor version upgrades are straightforward as the data on disk is guaranteed to be compatible. All it takes is a restart or switchover to upgrade.
Major versions are more challenging for "vanilla" Postgres because that's not the case. Storage/catalog formats may change. There needs to be an explicit upgrade process for the data (eg, a database created with v18 won't work out of the box with v19).
The cool thing is, software like Neki (and Vitess for MySQL, which we maintain) have architectures that lend themselves to making this much more feasible. Because the actual database nodes sit behind a router + parser layer with Pg/MySQL compatibility, the upgrades can be done transparently to the user. We plan to write more about how this works in the future.
Replies
You can do live parallel routing and blue-green migrations transparently. In your docs you already describe how to do it but the user has to do it manually at the application level when you can do it just fine at the DB load balancer/router level.
I believe most major versions of postgres only change metadata, so the downtime only scales with the size of the schema (usually small) and not the size of the data.