Parent was probably talking about the application server, which is the typical example of K8s usage, whereas most databases don't fit well there and are usually separate from the K8s cluster.

Yeah. They must be. I’ve had several k8s enthusiast dissuade from putting a db in k8s for performance reasons. This may change overtime but I believe there is a performance bottleneck in disk I/o (or at least that’s how it was explained to me)

That really depends on your k8s environment. If you're running on bare metal and use host bind mounts for storage, you won't have a problem. But as soon as you introduce shared storage it gets messy...

Doesn't that defeat the promise of k8 in the first place?

Because then it won't scale.

And the moment you do you run into other bottlenecks.

Meh, not having to worry about configuring load balancers and letsencrypt alone is worth the effort to get k8s running.

We've just migrated our ERP from a regular deployment on VMs into Kubernetes. We have a very bursty self-service component, so being able to scale up easily for the week we need it is quite nice. We've taken advantage of this ability multiple times and seen great success each time.

We're not running the DB in Kubernetes though.

Just curious, what backup/replication/disaster recovery solution(s) are you running with that?

Used to run Tivoli Storage Manager, now Commvault. Backup can be used for certain type of issues that are isolated to the database.

For DR, Entire stack is being continually synced with a set of hot server in separate datacentre. We run a fully DR exercise yearly and it works well. It's a fairly proprietary AIX / DB2 method though so not sure you'd find value unless you're using the exact same technology stack :-/