Databases on Kubernetes: yes or no?

For years, the standard advice was simple: run your stateless apps on Kubernetes, and keep your databases somewhere else. Kubernetes was built for cattle, and databases are the ultimate pet.

That advice is getting old. Storage on Kubernetes has matured, and operators can now handle failover, backups and upgrades better than many hand-built setups. So the question has changed from "can you?" to "should you?"

Storage on Kubernetes, simply

A few building blocks you need to understand:

• PersistentVolume (PV): a piece of storage, like a cloud disk.
• PersistentVolumeClaim (PVC): a pod's request for storage: "I need 50 GB of fast disk".
• StorageClass: the type of storage and how to create it automatically, for example SSD-backed cloud disks.
• CSI drivers: plugins that connect Kubernetes to the actual storage system.
• StatefulSet: like a Deployment, but each pod gets a stable name (db-0, db-1) and its own persistent volume that follows it.

With these, a database pod can be restarted or moved and still find its data.

But here's the catch: a StatefulSet only keeps the data attached. It knows nothing about database replication, failover, backups or upgrades. That's where operators come in.

Operators that do the hard work

An operator is software running in your cluster that knows how to run a specific database. You describe what you want, and it handles the operational details.

Some well-regarded ones:

• CloudNativePG for PostgreSQL: replication, automatic failover, backups to object storage, point-in-time recovery, rolling upgrades.
• Strimzi for Apache Kafka.
• Percona operators for MySQL, PostgreSQL and MongoDB.
• Redis/Valkey operators from several vendors and communities.

A PostgreSQL cluster with CloudNativePG looks like this:

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: orders-db
spec:
  instances: 3
  storage:
    size: 50Gi
    storageClass: fast-ssd
  backup:
    barmanObjectStore:
      destinationPath: s3://my-backups/orders-db
      s3Credentials:
        inheritFromIAMRole: true
    retentionPolicy: "30d"

Three instances, streaming replication, automatic failover and backups, in about fifteen lines. That's impressive.

A database on Kubernetes without an operator is just a database with extra ways to break.

Backups I trust

Whatever you run, the backup is what matters. A few rules:

• Use the database's own backup tools (via the operator) for consistent, point-in-time recoverable backups. Disk snapshots alone are not enough for most databases.
• Store backups outside the cluster, ideally in another region or account.
• Use Velero for backing up Kubernetes resources and volumes as a second layer, especially for disaster recovery of a whole cluster.
• Test restores regularly. A backup you've never restored is a hope, not a backup.

The real costs

Running databases on Kubernetes means your team owns things a managed service would handle:

• Upgrades of the database version and the operator.
• Performance tuning, storage sizing, and dealing with full disks at 2 a.m.
• Security patches.
• Expertise: someone needs to really understand PostgreSQL (or whatever you run) when things go wrong.

When I'd still pick a managed database

I'd choose a managed service (RDS, Cloud SQL, Azure Database, and similar) when:

• The database is business-critical and the team is small.
• Nobody on the team has deep database operations experience.
• You're already on a cloud provider and the managed option fits the budget.
• Compliance requirements are easier to meet with a certified managed service.

When Kubernetes makes sense

And I'd run it on Kubernetes when:

• You're on-premises or in a sovereign or edge environment without good managed options.
• You need many small databases, for example one per preview environment or per tenant.
• You want consistency across clouds.
• Cost matters at scale, and you have the skills to run it.
• The team already has strong Kubernetes and database experience.

So, yes or no?

It depends, but the answer is no longer "never". With a good operator, solid backups and a team that understands the database, Kubernetes is a perfectly reasonable home for state. Without those, a managed service will save you a lot of sleepless nights.

My take: the database doesn't care where it runs. It cares whether someone who understands it is looking after it.

— Desly