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.
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.
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.
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.