I'm not sure I follow you about local volumes and affinity rules. I followed instructions on kubernetes website to create local volume and pod which uses this l

I'm not sure I follow you about local volumes and affinity rules. I followed instructions on kubernetes website to create local volume and pod which uses this local volume was scheduled on the proper node every time. I think it works with volumeBindingMode: WaitForFirstConsumer option. So if you think that you need storage cluster either way, go ahead and deploy it. If you think that you're OK with single unreplicated database, just use local volume, it works. At least I've yet encounter any worm with this thing. For me it just worked. Another option is to use local volumes and replicated database setup. So you can run, say, two database instances in a replicated mode on two servers, but storage will be simple local volume. It provides some reliability and availability benefits without complex storage cluster solutions. I used cloudnative pg operator for this and it worked for me. I guess one can configure ordinary postgres replication without any operator, I just don't have experience with that. My opinion is that even single-node kubernetes cluster is worth it. That's because I have some experience and won't need time to learn basics. If someone does not have that experience, then I agree. Deploying kubernetes requires learning curve and that time might be spent for other things. At least it's hard for me to imagine any kubernetes complication that won't arise with, say, docker. At the same time, kubernetes provides lots of polished software line ingress-nginx, cert-manager, cloudnative-pg which could save some time. And, most importantly, using kubernetes from the start, provides very easy option for moving into cloud, for scaling, for zero-downtime deployments. Those things are valuable by almost everyone.