Hacker News Reader

Comment by conradfr | Hacker News Reader

Not totally ideal if you're using containers as it requires the binaries of the old and new version, unless I'm missing something.

View on HN

That's hardly a PostgreSQL issue. If your container tech does not allow installing both old and new version of the binaries, it's a silly container tech.

Well I use the official Postgresql docker image ;)

Also it looks like this is not new https://github.com/docker-library/postgres/issues/37

Note that the "official" PostgreSQL docker image is maintained by Docker Inc - not by PostgreSQL contributors/members.

Containerized DBs are great for dev work, toy projects, etc.

Notsomuch for production. I know... folks do it. But I wouldn't run anything on it that I wouldn't do w/ sqlite.

Why not? Having the whole application in one Kubernetes setup, with all databases and other services is very convenient. Are you talking about performance overhead, or are there other drawbacks to this approach?

The main problem is "persistent storage". In k8s, a PVC/PV is probably close to the right answer, but in general that gives you a file-system view of the storage, not a block-device view, which for some databases might matter).

Also, in general, that persistent storage is (generally) not locally attached, which means that (some) file system interactions may have unexpected semantics. Now, with a DB, you're probably only going to have the PV attached on a single worker node, so most of that will actually just work.

It does not make sense to run a rdbms in a container in prod; the entire OS is your container.

It makes sense for me using CapRover for my side projects (with multiple envs) all in one cheap server.

All distros I've ever used (debian, arch) provide previous and current version of postgresql for the purpose of easy pg_upgrade.

Debian even has special custom helper scripts for doing it. So just build your container with both postgres versions?

Reply on news.ycombinator.com