Should Production Databases Be Deployed in Docker/Kubernetes? A Critical Analysis

Docker: What Problems Does It Solve?

Docker markets itself as lightweight, standardized, portable, cost‑saving, efficient, and automated, which works well for stateless services but leads some teams to over‑containerize, including production databases.

Reliability

Databases are critical applications where reliability—surviving hardware faults, software bugs, and human errors—is paramount. Docker’s feature set does not explicitly address reliability, and the community’s fault‑tolerance knowledge is largely based on bare‑metal deployments, making troubleshooting harder when containers are involved.

Additional Failure Points

Introducing Docker adds extra components and complexity, increasing the overall failure surface. For example, if the dockerd daemon crashes, the database process stops, a failure that would not occur on bare metal.

Isolation

Docker provides process‑level isolation, which can be detrimental for databases. Running two PostgreSQL instances on the same data directory works on bare metal because the second instance detects the conflict, but Docker’s isolation can hide such conflicts, leading to data corruption without proper fencing.

Tools

Database maintenance tools (backup, extensions, monitoring) are typically designed for bare‑metal setups. Installing a PostgreSQL extension on bare metal is as simple as yum install and create extension postgis, whereas in Docker it requires modifying the Dockerfile, rebuilding the image, and restarting the container.

Command‑line workflows also become more cumbersome. A simple data copy using psql:

psql <src-url> -c 'COPY tbl TO STDOUT' | psql <dst-url> -c 'COPY tbl FROM STDIN'

needs to be wrapped in Docker exec calls when the client binaries are not present on the host:

docker exec -it srcpg gosu postgres bash -c "psql -c \"COPY tbl TO STDOUT\"" | \
  docker exec -i dstpg gosu postgres psql -c 'COPY tbl FROM STDIN;'

Backup commands similarly require multiple layers of docker exec, gosu, and pg_basebackup.

Maintainability

Docker excels at codifying infrastructure (IaC), making environment configuration reproducible. However, databases change infrequently, and DBAs already maintain scripts for setup and day‑2 operations, so Docker’s advantage is limited. Day‑2 tasks such as backups, restores, and upgrades often become more complex when wrapped in container commands.

Day‑2 Operations

Operations that are trivial on bare metal (e.g., running pg_basebackup directly) require additional Docker layers, adding overhead without clear benefit.

Performance

While Docker’s overhead is modest (typically <10%), any additional abstraction degrades database performance. For latency‑sensitive workloads, the extra kernel copies and isolation can be significant.

Conclusion

Containers and orchestration bring valuable automation for stateless services, but for production relational databases the trade‑off often means sacrificing reliability for marginal maintainability gains. Unless the use‑case tolerates reduced reliability, deploying critical databases in Docker/Kubernetes is generally not advisable.