This is great because it helps with understanding why for some long-standing projects it may not be feasible to incrementally change toward new API. And, it can be worth considering pioneering new breaking change versions that would bring new capabilities into being.
But typically, if you do spend some time to think about schema, and relationships, you only have to spend a small amount of time, and map that into the appropriate place, and then usually you don't have to mess with it again. It's worth the investment.
Many times, we don't realize how our brains/selves have been conditioned. It's kind of a luxury to even be able to have the time and space to gain this insight for many people.
I've been enjoying the journey of bringing Nix into the supabase community. There are some interesting challenges here, and we're already reaping some of the rewards. One of the most interesting and innovative things that has emerged has been to use nix to test upgrade/downgrade issues for postgres (as discussed in the blog post).
Nix has also made testing version of postgres, extensions etc in development far more streamlined, and I've spent time recently working with people internally to start to learn to leverage the ability to switch to any commit or branch, and build/run/test versions.