Hacker News Reader

I'm still not sure I follow. If you're not setting up a DB that will have such heavy usage that it needs bare metal access, what's wrong with setting it up such that it stores data on a NAS, or via mounted volumes? Then when it comes time to upgrade due to a security issue, you can create a new container, spin it up, and if it barfs, relaunch the old one.

View on HN

Unnecssesary complexity. A VM would've sufficed for what you described.

I find VMs are super slow for development purposes (I mean setup, starting up and shutting down rather than actual processing), where docker's made a massive difference. YMMV especially if you're not spinning up new projects frequently.

They might be a better solution in production, but I have a strong preference for production mimicking development.

Precisely the point. It's fine in dev but once you are running in prod and need rock solid stability the generally accepted dogma is that containerizing your DB is playing with fire. As you said, YMMV.

What is the "Unnecssesary complexity" in this scenario? You literally just run a command and you can spin up a new container with your data.

Reply on news.ycombinator.com