Broadly 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.
replyMajor 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.
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.
replyExactly. When you have a router + query parser in front of the db nodes, the burden of managing multiple versions simultaneously can be taken out of the app and into the database layer.
reply