I simply wanted to highlight that there are many ways to skin a cat, and "no shared tenancy" is not in itself a valid argument for hosting your DBs in k8s, even though there may be other good reasons.
There's always a point at which running things on Kubernetes becomes worth it. RDS is an expensive service, and if you want to enable every developer to boot up a development environment, or several even, if becomes prohibitivly expensive to use one process for everything. This is also true about running any workloads on Kubernetes to begin with though, and many companies definitely would be better off with a service like ECS/FarGate/CloudRun/Fly.io. Especially if they don't need the flexibility to build their own addon metrics/secrets/logging stacks.
Where I was the tooling was very focused on disposable api servers.
You can spend a lot of time getting databases and other stateful workloads to work -- mess around with StatefulSet and PVC on top of all the normal Kubernetes concepts, and what do you get in the end? Are you really better off than you would have been if you ran the database in EC2?
Plus, "herds not pets" kind of breaks down once you start using StatefulSets and PVCs. Those things exist to make Kubernetes more like a static environment for workloads that can't handle being run like ephemeral cattle. So why not just keep using your static environment?
If Kubernetes is the only workload management control plane you have, then I guess this makes sense. But if you are already able to deploy your databases with existing tools, and those existing tools don't really suck, it's probably not worth migrating. It would take a lot of time and introduce significant new risks and operational complexity without a compensating payoff.