When you're a child, birthdays are important because this is how you grow up. As a young adult, it's important for your social life. As a mid-life adult, it's depressing, because it's one more year closer to death...my birthday is now a source of anxiety, so I just don't celebrate it. But still happy to receive a present, which never happens anymore, sadly!
The truth is Kubernetes already has all the primitives to run database or any other stateful applications. What is challenging is how to make it reliable, performant and scalable for this kind of apps. If you manage to do it properly, then it will be far less costly and manageable than any DBaaS out there.
There are 2 dimensions to the problem:
1) How to easily deploy and operate a "production" DB in K8S. As the toolset evolves, we've seen a lot of different operators and customization tools to facilitate this. Today it is rather trivial to write the manifests that will deploy a Redis cluster fit to your needs.
2) You need a REALLY good kubernetes-native data service layer that guarantees fast failover, sync replication and performance for your persistent volumes. StatefulSets alone won't really help in case of node failure...and don't even think about using NFS. Ondat/StorageOS are leaders in that space, it's really simple to deploy, so you can give it a try in less than 5min.
Once you've made sure that your stateful configuration is right and that the network/data layer is reliable, then you can leverage all the visibility tools native to K8S (ELK/EFK, Prometheus, etc). Your stateful apps will be ready for CI and other DevOps integration using the K8S tools (Tekton, ArgoCD etc). This will make your devs happy as infra is not the blocker anymore...
I have to ask, do you have an interest in ONDAT/StorageOS? Because you say they're a leader and yet I've never run into them, your account is two weeks old, and I see they've just started a twitter account, so it all kind of smells like a PR push.
while you can -- and I've worked at shops that have -- and there are DBs like Cockroach that are k8s native... I still wouldn't. Give me a some VMs and I'll create a cluster. Sure it will be overprovisioned and such but it's a database. It needs to be solid and consistent and slow to change.
I still think it's best to allow K8s to coordinate ephermeral containers with little to no persistent storage and let the DBs be run more traditionally.
