Hacker News Reader

Comment by vetinari | Hacker News Reader

As others mentioned (it is slow, has problem with multiple users, cannot pin versions) it is also missing features the linux distribution have. For example, you cannot have Provides: alternatives as rpm/dpkg do, you must use packages for resolving dependencies as they are provided by upstream.

For example, when postgresql 12 was released, it took some months to appear in brew. Meanwhile you could not use alternate taps to resolve dependencies, if some package required postgres, it had to be the original one.

View on HN

Why would you install postgres through Brew though?

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.

Because if you need to ingest some data, it is much slower with Docker Desktop for Mac :/

Also, I have some tools installed with brew, that have postgres as dependency (e.g. pgloader or mapnik).

Not going to wade into the "should" or "shouldn't" of this, but I have used postgres-via-docker for ... few years now, and it is a DREAM. And I never have to worry about versions or dependencies (at least I haven't yet).

I've installed Postgres on my Mac with Homebrew, Docker, and https://postgresapp.com. There are arguments for each of them. On the pro side:

- 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.

> Those times are way gone, that's the purpose of containers.

Please elaborate on the claim that "running a SQL database" is the purpose of containers.

To be fair to GP, running sql database inside a container does have benefits for development, and in many situations, for deployment too.

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.

Why wouldn’t you want to run a database under namespaces and cgroups from a dependency-bundled live archive file tree?

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.

I think you're being unkind to containers. Yes it's easy to say that "containers aren't a thing" and then list all the little tools that are used to implement them. That doesn't make them not real any more than any other abstraction.

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.

Reply on news.ycombinator.com