Why you should deploy your database in a container (and why you shouldn’t)

I’ve been thinking about deploying a database as a container. It took me three years since the first time I become familiar with Docker because now I have a real working case.

My biggest question about deploying things with Docker, especially databases is “How about the storage?”. Classic databases depend so much on the storage system. Although there are query engines they can read from multiple kinds of storage types from a local path to a distributed system, classic database software have their own storage format and cannot interchangeable between software (i.e MariaDB and PostgreSQL data file).

Based on how they store the data, now we should make a clear line between database software and query engines. (Classic) database software maintains its own data store format which will be a piece of gibberish information if we try to read it without the software itself or other software that specialized to read it. While query engines usually read a more open-source data format which you can freely dissect the data using any kind of software and programming libraries.

We will talk about dockerized query engines later.

My question about how we store the data if we deploy this database software as a container in Docker seemingly solved with volumes. Docker comes with a handy feature called “Docker volume”. While it claimed to be easy to re-deploy elsewhere but is it really as easy as it claims for the case of database deployment as a container in Docker?

A week ago, I got the case of moving some containers to another machine. At first, I’m thinking about how to move docker volume between machines since the containers I wanted to move contains databases PostgreSQL databases at once. But then I saw these line in their docker-compose configuration:

volumes:
  - ./pgdata:/var/lib/postgresql/data

Now that’s helped me a lot. Since moving the containers is as easy as copy-paste. In reality, it’s not that simple either but really helped me a lot. To be honest, I could call it barbaric way, but hey it works! Now what I need to do is just stopping the containers, zip the whole directory, move it to the new machine, fire them up again, Voila!

Some obstacles I encountered that I should copy some images manually. But it still far fewer steps than moving docker-managed volumes. For these to be smoothly stopped into the last commit, I still need to warn users of service disruption and disconnecting them from the application so I can stop the container smoothly. Again, still much easier than any tutorial of moving the container volume out there.

My conclusion is mounting an external volume on the docker container will make things easier for maintenance. Well, that’s if we put aside some things like security since the path is completely visible to anyone who has access to the filesystem. Also, another consideration that makes this kind of container configuration is that it will be harder to move it to Kubernetes or a similar service.

Finally, deploying your databases into cloud-based databases will help you a lot in reducing maintenance time and effort. There are already a lot of cloud-based database services like AWS RDS, Google CloudSQL, Azure Database, etc. So, if your IT department has extra budgets to spare I think there is no sin to deploy a fully-managed database service on the cloud. And by the mean saving maintenance time, that includes keeping most system and security things to be handled by the cloud provider.