←back to thread

264 points davidgomes | 2 comments | | HN request time: 0s | source
Show context
KronisLV ◴[] No.41877633[source]
In many orgs out there, the version that's picked when a project is started will stick around for a while.

Suppose you join a project and see that the PostgreSQL version used is pretty old.

Do you:

  A) convince people to migrate it for some nebulous benefits (features that aren't currently used, performance improvements that will be difficult to measure in lieu of tooling and aggregated statistics) while also taking on the risks of breaking everything or even worse, data loss (since you won't always be able to provision multiple instances and backup restore might take a while and you could still mess that up)
  B) or just leave it as it is and focus on anything else
Many will prefer to not get burned even if there shouldn't be that many risks with upgrading your average PostgreSQL install, which is why you'll get minor/patch releases as best, alongside whatever the runtime environment is getting upgraded.

Containers and bind mounts make all of this way easier, but then again, many places don't use containers.

replies(1): >>41878298 #
1. gonzo41 ◴[] No.41878298[source]
So i've got a small but important app that I run on PG14 via a container. I literally just put the pgdata dir outside the container and I can keep the host OS totally fine and have an isolated db environment. it's a very nice way to not worry about the db.
replies(1): >>41878611 #
2. KronisLV ◴[] No.41878611[source]
Some might disagree (believing that the system package manager should be responsible for the PostgreSQL install), but I agree that the approach you’re using is one of the better ones.

That way you can update the database version when you want, while still installing the base system updates quite frequently. Plus, I think it’s really nice to separate the runtime from the persistent data, which such setups make obvious.