Why Running Production Databases in Docker Is Generally a Bad Idea

What Docker Solves

Docker describes itself as lightweight, standardized, portable, cost‑saving, efficient, automated, and well‑integrated. These attributes are valuable for stateless applications, but many companies try to extend them to every service, including production databases, which is controversial.

Reliability

Databases are core, critical components; their reliability is paramount. Reliability means the system continues to work correctly under hardware failures, software bugs, or human error. Unlike office software, a database outage can be fatal for a business.

Docker’s advertised features do not include reliability, a key safety attribute for databases. Community knowledge about failures is largely based on bare‑metal deployments, so containerized databases lack the same depth of proven reliability.

Reliability Proof and Community Knowledge

Proving reliability requires long‑term stable operation. Bare‑metal databases have decades of proven reliability; Docker, with only a few years of history, cannot yet provide the same confidence. Most failure‑handling knowledge assumes a non‑containerized environment.

Additional Failure Points

Containerizing a database adds extra components and complexity, creating new failure points. For example, if the Docker daemon crashes, the database stops—something that never happens on bare metal.

Issues can arise from interactions between Docker, the OS, orchestration systems, networking, and storage. The PostgreSQL Docker image’s issue tracker illustrates many such problems.

Isolation

Docker provides process‑level isolation, which is beneficial for many apps but can be problematic for databases. Two PostgreSQL instances sharing the same data directory can interfere when Docker’s isolation hides one instance from the other, leading to data corruption without proper fencing.

Tools

Database maintenance tools (backup, monitoring, extensions) are typically designed for bare‑metal installations. In Docker, installing an extension like PostGIS requires modifying the Dockerfile, rebuilding the image, and redeploying, which is far more cumbersome.

Package managers, monitoring agents, and ad‑hoc tools often behave differently inside containers, requiring work‑arounds that increase operational overhead.

Maintainability

While Docker excels at “infrastructure as code” for stateless services, databases rarely need frequent re‑deployment. DBA scripts and configuration management already provide repeatable setups, so Docker’s advantage here is limited.

Day‑2 Operations

Database containers cannot be freely created, destroyed, or migrated like stateless app containers. Routine tasks still require docker exec wrappers, adding unnecessary layers. Complex commands such as physical backups become multi‑step Docker‑centric procedures.

Version upgrades that are a single command on bare metal become elaborate Dockerfile rebuilds and container restarts, especially for major version jumps.

Performance

Performance is another concern: additional isolation layers introduce overhead, and databases benefit from being as close to the hardware as possible. Docker typically incurs a modest (<10%) performance penalty, which is undesirable for latency‑sensitive workloads.

Conclusion

Container and orchestration technologies bring great value to operations, but for production relational databases they currently add more complexity and risk than benefit. They are suitable for development, testing, or non‑critical services, but for critical production databases, placing them in Docker is generally not a wise decision.