Those times are way gone, that's the purpose of containers.
I've been using Brew for a while to just install "core" packages like python, curl, wget and such, and everything else like a postgres, nginx, whatever..a go to a container.
Those times are way gone, that's the purpose of containers.
I've been using Brew for a while to just install "core" packages like python, curl, wget and such, and everything else like a postgres, nginx, whatever..a go to a container.
Also, I have some tools installed with brew, that have postgres as dependency (e.g. pgloader or mapnik).
Please elaborate on the claim that "running a SQL database" is the purpose of containers.
However, if I do some exploratory experiments, where I don't care about repeability and where I use other local tools (like the mentioned mapnik, or jupyter), having it in container is needless complication.
By and large, there’s no such thing as a container, there’s just sprinkles of housekeeping magic. To wit, Docker implemented in around 100 lines of bash:
https://github.com/p8952/bocker
Problems come when we think that today’s containers manage to actually contain anything, bring any security guarantees, or do much else than just slightly-more-successfully jump start a configurable bundle of dependencies.
Why wouldn't you want to run a database under VT-x, with random emulated hardware and a dependency-bundled disk image? By and large there's no such thing as a VM, there's just sprinkles of housekeeping magic?
Containers as specced and implemented do come with security guarantees. And if they fail to meet them it's a bug.
- Homebrew is a general purpose package manager, and Postgres is a package you might want managed.
- If you're using Docker/Docker Compose for a project anyway, that's the obvious way to do it.
- Postgres.app is a specialized tool just for managing Postgres installs, so it's hard to beat if that's what you need.
Some thoughts on the tradeoffs though:
- Homebrew really doesn't like the idea of "versions". It wants everything to be on the latest. That can be fine if you just need a tool locally, but if you want dev and prod to match, it is a pain in the ass.
- Docker isn't really very good at persistence. That's probably not a problem for local development, but you should be aware of it. Running it on a Mac introduces speed and memory issues you wouldn't otherwise have. And now obviously there's the M1 problem.
- Postgres.app is another thing to install. If you just need Postgres for one particular project you might not know about it or want to deal with installing something new.