Docker, and Kubernetes is still a rapidly evolving technology and there are too many horror stories of it crashing and burning in production for it to be worth it, in my view. Databases are not immutable, and even though Docker has persistent volumes it is still new and evolving. If the database breaks in some way, I don't want to have to worry about the new container having a slightly different patch level and that messing up the database. I don't want to have to worry about rebuilding my database cluster to upgrade it.

Google might do some really cool shit with Kubernetes, but they are Google. I don't think using them as a good example for anything but infrastructure on a massive scale is correct. They are years ahead of everyone else, and if they are doing something in production, they have been testing it for years. If shit hits the fan, they have thousands of employees to throw at the problem. GitLab is building a team, and therefore does not have the experience to know these systems inside and out. In my view, using Docker/Kubernetes is adding unnecessary complexity to the database fabric for minimal tradeoffs.

And considering that they are speaking out dedicated database servers, it makes no sense to add a unneeded layer of abstraction when in all likelihood the container will be bound to a node.