Why Running MySQL in Docker May Not Be Ideal: Data Safety, Performance, and Resource Isolation Issues

A container is defined as a solution to ensure software runs correctly when switching execution environments.

The article discusses the hot debate on whether the MySQL database should be containerized, presenting arguments from both proponents and opponents.

Data safety issues: Storing data inside a container is discouraged because containers can be stopped or removed, leading to data loss; using volumes mitigates this but still lacks strong guarantees, and sudden crashes can corrupt data.

Performance issues: MySQL is I/O‑intensive; running multiple instances in Docker can cause I/O bottlenecks, reducing read/write performance, as noted by architects from large enterprises.

State issues: Docker’s rapid horizontal scaling is designed for stateless services; databases require persistent state, so they are not well‑suited for direct deployment in Docker without external storage solutions.

Resource isolation: Docker relies on cgroups for resource limits, which cannot fully isolate resources like a VM; heavy resource contention on the host can degrade MySQL performance.

Nevertheless, MySQL can be containerized in certain scenarios: workloads insensitive to data loss, lightweight or distributed databases that can be automatically restarted, and architectures using middleware for scaling and disaster recovery.

Typical examples of successful MySQL containerization include cases from companies such as Tongcheng Travel, JD.com, and Alibaba.