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.