Should You Run Databases in Docker or Kubernetes
Advanced4 minInnovialabs editorial team
In short
Docker is ideal for databases in local development and CI; in production, small teams are usually better off with a managed database, while running it in Kubernetes pays off only with a mature operator and people who can operate it.
The short answer
Yes for development and testing: a database in Docker gives everyone the same version in seconds. For production the question is not "can containers run databases" (they can) but "who will handle storage, backups, failover and upgrades at 3 a.m.".
- No dedicated ops people: use a managed database from your cloud provider.
- Already on Kubernetes, with engineers who know it well: a mature operator such as CloudNativePG is a reasonable choice.
- In between: a database on a dedicated VM, possibly in Docker, with automated and tested backups.
What really matters
Storage performance. Databases are sensitive to disk latency. Network-attached volumes are convenient but slower than local NVMe disks. Local volumes are fast but tie a pod to one node, so if the node dies, recovery depends on replication rather than reattaching the disk. Benchmark the actual storage class with your workload.
Persistence. Data must live on a volume, never in the container's writable layer. In Kubernetes, use a StatefulSet or an operator with PersistentVolumeClaims, and set the reclaim policy so deleting a claim does not silently delete data.
Backups. You need both regular full backups and continuous archiving of transaction logs for point-in-time recovery, stored outside the cluster, for example in object storage. A backup that has never been restored is a hope, not a backup: schedule restore tests.
Failover. One database pod is a single point of failure. High availability needs replicas, automatic leader election and clients that reconnect to the new primary. This is the hardest part to build yourself, and the main reason operators exist.
Operator maturity. An operator encodes DBA knowledge: replication, failover, backups, minor upgrades. For PostgreSQL there are several established options, including CloudNativePG, Zalando's postgres-operator and Crunchy PGO; Percona maintains operators for MySQL, PostgreSQL and MongoDB. Check project activity, documentation, how upgrades and restores work, and whether anyone on your team has used it in production.
Resources. Set memory requests and limits carefully: if the container exceeds its memory limit, it is killed, which for a database means a crash and recovery. Avoid placing databases next to noisy workloads.
Managed vs self-hosted
| Factor | Managed database | Self-hosted in Kubernetes |
|---|---|---|
| Setup effort | Low | Medium to high |
| Backups and PITR | Built in | Configured via operator |
| Failover | Provider handles it | Operator handles it, you own it |
| Control and extensions | Limited by provider | Full |
| Portability, on-prem | Tied to provider | Same setup anywhere |
| Cost drivers | Instance size, storage, traffic | Nodes, storage, engineer time |
People's time is the cost most often forgotten. A self-hosted cluster that saves on the bill but needs constant attention is rarely cheaper.
Decision framework
By team size:
- 1–5 developers, no DevOps: managed database. Docker Compose for local development and CI only.
- Team with one or two DevOps engineers: managed database by default; self-hosting for non-critical or internal systems, or where data must stay on specific hardware or in a specific country.
- Platform team running many services: an operator in Kubernetes can standardise dozens of databases, with runbooks, monitoring and regular restore drills.
By workload:
- Latency-sensitive OLTP with heavy writes: dedicated nodes with fast local storage, or a managed service with provisioned IOPS.
- Preview environments, tests, short-lived stands: a database in Kubernetes is ideal, since data is disposable.
- Caches and queues (Redis and similar): easier to run in containers, especially when data can be rebuilt.
- Large analytical workloads: usually belong on specialised services or dedicated machines.
Common mistakes
- Data stored inside the container instead of a volume.
docker compose down -von a server, which removes named volumes along with the data.- A Deployment with one replica instead of a StatefulSet or operator.
- Backups stored on the same cluster or disk as the database.
- Database ports open to the internet.