Hacker News Reader

Comment by railorsi | Hacker News Reader

What’s the issue with running Postgres inside a docker container + regular backups? Never had problem and relatively easy to manage.

View on HN

Why use a docker container? I run Postgres as is, what would I gain with running it in a container?

It makes the whole thing is configured in a docker-compose file (or your raw Docker CLI invocation) + the data volume. So as long as you have those two things you can replicate it and move it to other hosts regardless of their distro.

Compare that with using your distro's packaged version where you can have version variations, variations in default config or file path locations, etc.

You can decouple Postgres and surrounding userspace upgrade cycles from your host os, if this is something that you want. Or run multiple different PG versions (have independent upgrades schedule) without being tied to the host os specific mechanisms for that.

no PITB, but mostly just 'it's hassle' for the application server I literally don't need backups, just automated provisioning/docker container etc. Adding postgres then means I need full backups including PITB because I don't even want to lose an hours data.

Or use SQLite and your backups are literally a copy of a file.

You can abuse git for it if you really want to cut corners.

Only if you can freeze your application for that long, in which case your statement is true for all non-broken databases.

It only freezes your application if you've misconfigured it.

If you want to backup your database using just a file copy, you'd better freeze your database if you value your data. Or use a fancy snapshotting filesystem.

You can easily do consistent backup on live databases. There’s a backup command and API.

Sure. But then it's not "just a file" copy, like GP said.

Reply on news.ycombinator.com