Why Deploying MySQL in Production Containers Is a Bad Idea

Why MySQL is generally not recommended to run in containers in production

1. Persistent storage requirements

Containers are ephemeral ; when a pod is restarted or recreated its filesystem is lost. To keep MySQL data durable you must mount an external volume, typically a PersistentVolume (PV) bound to a PersistentVolumeClaim (PVC). In multi‑node Kubernetes clusters this introduces several problems:

Cross‑node volume attachment can be complex and may fail, leading to unavailability.

Host‑local volumes such as hostPath have poor resilience because the data lives only on a single node.

Networked storage solutions (NFS, Ceph, GlusterFS, etc.) can add latency, packet loss, and I/O jitter, which degrade database performance.

Misconfigured or unavailable volumes can cause data loss or a complete database outage.

2. Network impact

Most Kubernetes clusters use an overlay network (e.g., Flannel, Calico). Compared with direct host networking, an overlay adds an extra forwarding hop, increasing round‑trip latency for every query. Additional network side‑effects include:

Variable latency can slow query response times.

Pod IP addresses change when a pod is recreated, breaking MySQL replication channels that rely on static endpoints.

Overlay networks may experience packet loss or temporary partitions, causing replication breaks.

In production, a database timeout or disconnection can cascade to affect the entire platform.

3. Performance considerations

MySQL expects a stable execution environment:

Dedicated CPU cores and predictable memory allocation.

NUMA affinity to keep memory accesses local to the CPU socket.

Exclusive or high‑priority I/O bandwidth for the data directory.

In a typical Kubernetes pod these guarantees are weak:

Pods are scheduled to any node with available resources, so hardware characteristics (CPU speed, cache hierarchy, disk type) can vary widely.

Multiple containers share the host’s CPU, memory, and I/O, leading to resource contention.

Horizontal scaling or pod eviction triggers live migrations, which are unsuitable for stateful workloads because the in‑memory state cannot be transferred.

Frequent pod migrations and resource contention cause unstable performance or crashes for MySQL.

4. Data consistency and replication challenges

MySQL’s high‑availability features (binary logs, GTID‑based replication, point‑in‑time recovery) rely on a stable host identity and continuous access to the data directory. Container lifecycles break these assumptions in several ways:

The primary pod crashes and is recreated with a new IP address, causing replicas to lose their connection.

Pod restarts may delete the binary log files before they are shipped to replicas, breaking replication.

If the PVC is not re‑attached before the new primary starts, the whole database becomes unavailable.

These failure modes are common in Kubernetes and can lead to data inconsistency or full outage.

5. Deployment recommendations

Running MySQL in containers is acceptable for non‑critical environments where data loss is tolerable:

Local development and debugging.

Automated testing pipelines.

Learning labs or tutorial demos.

For production workloads, prefer one of the following approaches:

Deploy MySQL on virtual machines or bare‑metal servers where storage, networking, and resource isolation are under direct control.

If containers must be used, employ a StatefulSet with a dedicated PVC and node affinity (or nodeSelector ) to bind the pod to a specific node, ensuring the volume and network identity remain stable.

Layer a proven high‑availability solution on top of MySQL, such as MySQL Group Replication, ProxySQL, or a managed cloud database service, to handle failover and scaling.

In summary, the transient nature of containers, overlay networking, and complex persistent‑volume handling conflict with MySQL’s requirements for durability, low latency, and strong consistency, making containerized MySQL unsuitable for most production scenarios.