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…

Thanks for taking care of that! Please let me know if your legal team finds anything wrong. If you need to contact me, either open a GitHub issue on the repo, or email me (maciej at 3ofcoins dot net).

We don't plan to do such a thing, but we would (obviously) be supportive. The challenges for a Docker daemon on SmartOS are several-fold: first, while clearly sympathetic to cross-platform concerns, Docker itself isn't actually (yet) cross-platform, and many Linux-isms were found in putatively generic code. Second, the Docker daemon has a hard dependency on cgo, which is even nastier than Go itself to get working on non-Linux systems. (We did ultimately get cgo working on illumos -- albeit arguably at the cost of the sanity of the engineer who did the work.[1]) Finally, in terms of deploying this into production, we're not about to take third party code from anyone and run it in the global zone on production machines.

So for us, it makes much more sense to implement the Docker Remote API on top of SmartDataCenter, which has the added advantage of virtualizing the concept of a Docker host to be an entire datacenter. But again, we would be supportive of any effort to straight-up port Docker to SmartOS, and we are generally supportive of any container effort that is looking beyond the (mis)design of Linux containers (including the work linked to here for FreeBSD + ZFS).

[1] http://dtrace.org/blogs/wesolows/2014/12/29/golang-is-trash/