Why MySQL May Not Be Suitable for Containerization and When It Can Be

A container is defined to solve the problem of ensuring software runs correctly when switching runtime environments.

Containers and Docker are currently the hottest terms in technology, and a hot debate has emerged: Does MySQL need to be containerized?

Supporters often cite only the advantages of containers without validating business scenarios, while opponents point out performance, data‑security, and other factors, providing examples of unsuitable cases. Below are several reasons why Docker is not ideal for running MySQL.

Data Security Issues

Do not store data inside the container; containers can be stopped or removed at any time, causing data loss. Users should use volume mounts to persist data.

Docker volumes are built on Union‑FS image layers and do not guarantee data safety. Sudden container crashes or improper shutdown can corrupt the database, and sharing volume groups can also stress the host hardware.

Performance Issues

MySQL, as a relational database, has high I/O requirements. Running multiple instances on a single physical machine aggregates I/O, leading to bottlenecks and significantly reduced read/write performance.

An architect from a state‑owned bank noted that database performance bottlenecks usually appear at the I/O layer, and Docker’s approach of multiple containers further concentrates I/O requests on storage, which discourages migration of databases to Docker.

Possible mitigation strategies include:

1) Separate database program from data

Store data on shared storage while keeping the program inside the container. If the container or MySQL service fails, a new container can be started automatically. Avoid storing data on the host to reduce impact on the host machine.

2) Use lightweight or distributed databases

Deploy lightweight or distributed databases in Docker; Docker’s design expects services to restart automatically rather than continue failing.

3) Properly place high‑I/O applications

Deploy databases on physical machines or KVMs for better performance; examples include Tencent Cloud TDSQL and Alibaba OceanBase, which run directly on physical hardware.

State Issues

Docker’s horizontal scaling is intended for stateless compute services, not for stateful databases.

The rapid scaling feature of Docker relies on statelessness; databases require dedicated storage services and cannot be directly placed in Docker containers.

Resource Isolation Issues

Docker uses cgroups for resource limits, which can set maximum consumption but cannot fully isolate resources from other programs. Excessive resource usage by other applications on the host can degrade MySQL’s read/write efficiency.

Higher isolation levels increase resource overhead, making dedicated environments more suitable for databases.

Can MySQL Not Run in Containers?

MySQL can be containerized in certain scenarios:

Workloads that are not sensitive to data loss (e.g., user search) can use sharding to increase throughput.

Docker is suitable for lightweight or distributed databases; if the Docker service fails, a new container is started automatically.

Using middleware and container orchestration enables automatic scaling, disaster recovery, and multi‑node deployment.

Typical cases include Tongcheng Travel, JD.com, and Alibaba, which have successfully containerized their databases.