I would be far more willing to entrust a production DB to a jail than a docker container because it's been audited over the course of >a decade. Furthermore, aboutthebsds is a well-known linux polemicist blog.
My main use of Docker is for making application deployment less painful. I've heard of a few people who say they're running their prod DBs under docker but I cannot begin to imagine how fucktarded you'd need to be to do this (unless they have some requirement to spin up lots and lots of short-lived dbs, and those dbs have very, very low storage performance requirements...)
I don't think that beginning your question with "I cannot begin to imagine how fucktarded you'd need to be to do this" is going to encourage people to answer that question…
That aside, my approach with Linux/Docker is to have a "fat" host system that is open to the outside world, terminates SSL, load balances and proxies the containers' services (nginx), and provides global services are either shared between containers (Postfix smarthosting to Sendgrid, DNS cache, rsyslog), or services that can manage user/service isolation well enough on their own (PostgreSQL). Containers run mostly applications, or services that I need in multiple instances or versions.
I do containerize Redis, as it can't be safely shared across multiple services (no privilege isolation, too easy for one service to DoS the other with a blocking operation), but then I don't consider Redis to be a database – it's rather a "shared state server", kind of a more sophisticated memcached.
However, I understand the approach of CoreOS, which minimizes role of the host OS. In this model, host's only role is to support containers, and every other process needs to be containerized. From this point of view, Postgres is an application. This way, I can flexibly run multiple version of Postgres, try to upgrade it without needing to set up separate host service, and so on. Personally, I wouldn't feel comfortable with that, but I understand how it could be useful.
Regarding storage performance, database's data directory would need to be a volume anyway (to be able to upgrade database without trowing away the data). A volume is just a `mount --bind`, without any aufs layers, to any point of the filesystem, so it doesn't seem to me that i/o performance hit would be noticeable…
There's nothing wrong with jails. Its a robust technology that's been battle tested for a decade. They provide lots of awesome features that are useful for reasons other than security. In fact, the primary reason I use jails is not for security at all. And, AFAIK there are no exploits in the wild for jails. Like any containerization or virtualization technology there are theoretical holes. I'd stake a large sum of money that we see major vulnerabilities in LXC/Docker in the next 5 years, we just haven't because they haven't been around as long.
I'd love to see a source for just about anything that blog claims because it reads like FUD and contains some factual inaccuracies like chroot not being in FreeBSD by the time jails were added. It also doesn't seem to understand what the difference between the base and the kernel is in FreeBSD. Jails are implemented similarly to LXC/Docker by having a few syscalls in the kernal for namespace isolation and the bulk of the execution happening in userspace.
VPS seems to require VIMAGE, which currently is a no-go for me (I experience kernel panic on boot if I compile it in), and the second link… well… the tinfoil hat of the author's blog has to be impressive. I've tried to read this and some other rants (they pop up quite high in search results), and couldn't find any actual content or any sources for the statements.
Capsicum and rctl are definitely on my list of things to look into (especially capsicum, it seems to be enabled in the GENERIC kernel configuration).