Why MySQL Should Not Run in Docker Containers: Data Safety, Performance, State, and Resource Isolation Issues

Containers are defined as a solution for ensuring software runs consistently across different environments, but the question arises whether MySQL should be containerized.

Data Safety Issues – Storing data inside a container is discouraged because containers can be stopped or removed, leading to data loss; volumes provide persistence but do not guarantee data integrity, and crashes may corrupt the database.

Performance Issues – MySQL, as a relational database with high I/O demands, suffers when multiple instances share the same physical host, creating I/O bottlenecks that degrade read/write performance. Strategies include separating the database program from its data, using shared storage, deploying lightweight or distributed databases, and placing high‑I/O workloads on physical machines or KVM.

State Issues – Docker’s strength lies in scaling stateless services; databases maintain state and therefore are not suitable for horizontal scaling within Docker without external storage solutions.

Resource Isolation – Docker relies on cgroups to limit resource usage but cannot fully isolate resources; excessive consumption by other applications can impact MySQL’s efficiency.

While MySQL is not entirely unsuitable for containers, it can work for workloads insensitive to data loss, lightweight or distributed databases, and scenarios leveraging middleware for auto‑scaling and disaster recovery. Notable examples include containerized databases used by companies such as Tongcheng Travel, JD.com, and Alibaba.