https://eng.uber.com/dockerizing-mysql/
Quote from that Uber article:
All of this means that you should really only use Docker if you’re willing to invest quite a lot of resources in it. Furthermore, Docker should be treated as a piece of technology, not a solution to end all problems. At Uber we did a careful design which had Docker as one of the components in a much bigger system to manage MySQL databases. However, not all companies are at the same scale as Uber, and for them a more straightforward setup with something like Puppet or Ansible might be more appropriate.
Most of the reasons involve crashing/instability and management/scaling properly. Resources also becomes a concern especially with the added latency of docker itself, Red Hat’s Podman has solved a lot of the network latency issues but you are still injecting another level of virtualization and the added latency.
Most databases are designed to be extremely latency sensitive (both network and Disk/Memory I/O) and where possible Dedicated hardware with a private LAN (Don’t expose your database to the public internet, looking at you Atlas).
The goal of containers is to provide a stable and repeatable environment to run a scalable application (typically dynamically) and you would not be dynamically scaling your Database cluster.