Why MySQL Is Not Ideal for Docker: Data Safety, Performance, and Resource Isolation Concerns

Containers are designed to ensure software runs consistently across environments, but the suitability of containerizing MySQL is heavily debated.

Data Safety Issues

Storing data inside a container is risky because containers can be stopped or removed, causing data loss; using volumes mitigates this but does not guarantee durability, and crashes can corrupt the database.

Performance Issues

MySQL’s high I/O demands suffer when multiple instances share the same physical host, leading to I/O bottlenecks and reduced read/write throughput; experts note that Docker’s shared‑storage model can exacerbate these limits.

1) Separate database program from data

Place data on shared storage while keeping the MySQL process in the container, and avoid storing data on the host’s volume to reduce impact on the host.

2) Use lightweight or distributed databases

Deploying such databases in Docker leverages automatic container restart on failure.

3) Proper application placement

High‑I/O databases are better run on bare metal or KVM; services like Tencent Cloud TDSQL and Alibaba OceanBase run on physical machines.

State Issues

Docker’s horizontal scaling is intended for stateless services; databases require persistent state, so they are not suitable for direct scaling within Docker.

Resource Isolation

Docker uses cgroups to limit resource usage but cannot fully isolate resources; heavy host usage can degrade MySQL performance, and achieving strong isolation incurs higher overhead.

When MySQL Can Be Containerized

Certain scenarios are acceptable: workloads tolerant of data loss, lightweight or distributed databases that benefit from automatic restart, and setups using middleware for auto‑scaling and disaster recovery.

Examples include travel platforms and e‑commerce sites that have successfully containerized their databases.