For complex services (maybe as simply defined as need low latency durable high-write-rate storage) - I'm not even sure if you should run it on a k8s pod. K8s of

For complex services (maybe as simply defined as need low latency durable high-write-rate storage) - I'm not even sure if you should run it on a k8s pod. K8s offers some "services", notably storage - that afaik don't typically run "on" k8s, but "as part of" k8s. I think databases (for production use) are better off managed as services? So typically on physical hw next to the hw that runs k8s? The alternative (as mentioned here) is to guarantee local storage on same hw next to the pod running the DBs - and you'd typically want to dedicate cpu, io and ram to the db - probably dedicate physical hw to the db pod(s). Maybe k8s can take care of failing over to a follower - but I don't think that's likely to work without a "plug in" in k8s for your db of choice? Maybe someone running redshift, spanner or azul sql service have some insight? Ed: for development and testing, that's another matter. But even then I think I'd prefer "provision a new db/schema on my beefy db service" to spinning up a pod that just happens to run a db daemon.