So you want to build a system that should be persistent and scale also in the future but at the same time you don’t want to use the very software that was invented to do exactly this?

You can spin up a postgres instance somewhere for almost free and then connect to it using a query string. It can’t get any easier than this.

If you are not happy with the supplier of your DB as a service, you simply dump it, spin up a new copy somewhere else, load the dump and bob’s your aunty.

I would focus my efforts on trying to solve business problems and not re-invent things like performant persistent storage.

Sorry, I wasn’t trying to twist your words. I just saw that migration as a problem, but I see it wasn’t, only an opportunity you took to improve your system.

Thank you all for your replies. I learned a lot today

Postgres releases require the use of pg_upgrade for major versions, while minor versions will migrate seamlessly. Every distro handles this differently, but Arch specifically expects you to do the upgrade yourself. It’s a minor nuisance, but major Postgres releases only happen once a year.

Edit: Forget to mention, but on Debian, I think most people use the official apt repo the Postgres team provides, which namespaces by version number. So, you never get caught off-guard with a version change while installing updates. Or they provide the option of using one that automatically upgrades and migrates for you, always keeping it the latest version without hassle. That’s what do personally.