This post is part of our CouchDB Tips Series (RSS) that we publish every week. The team at Neighbourhoodie works on and with CouchDB every day and we are happy to pass on all the tips and tricks we learn along the way. If you like what you see, check out our Professional Services for CouchDB, including production support and training. If you want to continuously ensure that your CouchDB is running optimally, sign up for Opservatory, our 24/7 CouchDB analysis and diagnostics tool.
Docker is an extremely popular way of deploying any kind of application in many different environments. Deploying CouchDB is no exception, the CouchDB project even maintains its own set of Dockerfiles, as well as a helm chart to help orchestrate multiple containers as a cluster on Kubernetes.
All of these are rather advanced concepts that we are not going into in this article. But if you need any particular help with this, we’re always happy to help.
First off, Docker is a fine choice in many cases:
We have many CouchDB customers and users that use CouchDB successfully inside Docker.
The way Docker works can introduce problems when running CouchDB in high-performance situations.
One of Docker’s core features is isolation of containers. In order to achieve this, Docker introduces a virtual networking and a virtual file system layer. Both of these layers can introduce delays and consistency issues to the point where running CouchDB inside Docker is slower than outside of Docker.
As a database, CouchDB naturally has the highest demands on data access. Any additional delays ingetting bytes to and from disk are going to make all CouchDB operations slower.
As a networked database, the same is true for Docker’s networking layer. Especially when running a CouchDB cluster in Docker containers, the networking layer leads to significant performance degradation.
We are constantly evaluating new versions of Docker and we’ll be happy to report when running CouchDB inside it is flawless. But until then, we’ll maintain this warning.
And sometimes, there is just the odd unexplainable issue.
In conclusion: there are many valid use-cases for running CouchDB inside Docker, and you might even make a conscious trade-off where the ease-of-use of Docker trumps the required performance for your database, or your load is just not that bit relative to the computing resources you have available.
But if you need to have CouchDB be its fastest and most reliable self, you should run it outside of Docker.