Where do you see the limitations of Brew? Despite it being a little wonky on beta releases of a new macOS iteration it works fine for me.

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.

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.

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

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.