I am currently researching approaches for moving our application to Docker containers and stumbled upon a question to which I could not find a clear answer.
Our application has several separate databases that are currently hosted in one database server. When moving to Docker should we keep the architecture similar (i.e. one container with all databases) or should we use one container per database?
The latter approach seems more "docker" to me. Similarly to not hosting 2 applications in one container, it seems to make sense to also not host 2 databases in one container.
Are there any established best practices? Does it depend on the parameters of the databases in question (size, access frequency, etc.) or the used database server (SQL server, PostgreSQL, etc.)?
As far as I can tell the "container per DB" approach gives more flexibility (e.g. enforce memory limit per DB) at the cost of more overhead (i.e. the database server overhead is incurred once per database instead of just once in total). Are there any other advantages/disadvantages I should consider?
Best Answer
Last time I checked it is not recommend to run databases in docker.
Simply put docker is designed to be a stateless container that you can spin up and take down as required. Where as Databases are very state-full indeed!
With a naive docker database approach you would lose all your data if the container crashed. If you span up a new instance you would get a blank database.
This might be ideal for development environments, but its very bad in production.
Now you can do some clever stuff with volumes, but you really have to ask yourself why you are attempting this thing. Databases are generally very mature products, with various backup, fail-over and high availability options built in. Generally you don't want to run them in containers as they already have the concept of containers built in.