Introduction
Most small to mid-sized organizations running Kubernetes follow a familiar pattern:
- Databases are deployed as StatefulSets
- Mostly open-source databases
- Backups are either:
- Partially configured, or
- Not configured at all
- Disaster recovery (DR) is an afterthought
Everything seems fine — until the database crashes.
That’s when teams stop building features and start panic-driven repairs.
This post is not about how to run databases on Kubernetes.
It’s about asking a more important question:
Are you solving the right problem by running databases yourself at all?
The Reality: Databases as Kubernetes Workloads
In many teams, databases are treated just like any other Kubernetes workload:
- MongoDB as a StatefulSet
- MySQL as a StatefulSet
- Dgraph, Redis, Elasticsearch — all running inside the cluster
The assumption is simple:
“If applications can run on Kubernetes, databases can too.”
Technically true.
Operationally dangerous.
Backup: The First Cracks Start Here
Some open-source databases provide built-in backup mechanisms.
Many don’t — or require significant setup.
So teams usually fall back to:
- PVC snapshots
- Scheduled volume backups
- Manual scripts
This introduces several risks:
- Snapshots are often untested
- Restore procedures are undocumented
- Backups are treated as “done” once configured
- No one actually practices recovery
Backups exist — but confidence does not.
When the Database Crashes
This is where the real cost shows up.
A typical incident looks like this:
- Database pod goes down
- StatefulSet fails to recover cleanly
- Data inconsistency appears
- Application errors start cascading
- Business teams ask for timelines
Only then do teams realize:
- There is no proper DR
- Restore time is unknown
- Data integrity is uncertain
- The team is now in firefighting mode
The problem was not Kubernetes.
The problem was operational ownership of databases.
The Hidden Cost Nobody Calculates
Let’s take a real example.
Assume you are running:
- 5 MongoDB StatefulSets
- Or MySQL / Dgraph / similar databases
Each typically consumes:
- Dedicated nodes (or heavy resource reservations)
- Persistent volumes
- CPU & memory buffers
- Backup storage
- Monitoring overhead
- On-call operational effort
Now ask a simple question:
What is the actual monthly cost of running these databases on Kubernetes?
This includes:
- Node costs
- Storage costs
- Backup costs
- Engineering time
- Incident handling
- Opportunity cost of not building features
Most teams never calculate this fully.
The Managed Database Question
Now compare that with:
- Managed MongoDB
- Managed MySQL / PostgreSQL
- Cloud-native managed databases
Yes, managed databases:
- Cost slightly more on paper
- Reduce control over internals
But they also give you:
- Automated backups
- Point-in-time recovery
- Built-in high availability
- Tested DR workflows
- Reduced operational burden
- Fewer panic situations
Most importantly:
They free your team to focus on the business.
A Better Way to Think About It
Instead of asking:
“Can we run this database on Kubernetes?”
Ask:
“Should we be operating this database ourselves?”
For many small to mid-sized organizations:
- Kubernetes expertise exists
- Database operational expertise often doesn’t
- Downtime hurts more than infra costs
- Reliability matters more than control
Running databases yourself shifts focus away from the real problem.
When Running Databases on Kubernetes Makes Sense
There are valid cases:
- Strong database expertise in-house
- Clear backup and DR strategy
- Regular recovery drills
- Compliance or data locality constraints
- Cost models that genuinely favor self-hosting
But these are intentional decisions, not defaults.
Final Thoughts
Running databases as Kubernetes deployments is often a cost optimization illusion.
The real cost is paid later:
- During outages
- During data loss scares
- During unplanned maintenance
- During missed business opportunities
If you’re already using cloud services, ask yourself honestly:
Could a managed database, at the same or slightly higher cost,
reduce operational stress, incident risk, and long-term maintenance?
In many cases, the answer is yes.
The goal is not to run everything on Kubernetes.
The goal is to run your business smoothly.
What’s Next on rebash
rebash focuses on real-world engineering decisions — not trends, not hype, and not defaults.
👉 Read more production-focused insights on rebash
👉 Follow along for practical DevOps and cloud lessons