Sure, and containers are just plain processes on a VM. The exact code that controls processes in a VM, also controls processes inside a container.
As long as the underlying data volume is reliable, it really doesn't matter whether you're running it outside of a container or not. Volumes for K8s have a come a long way since its early days.
But running a database in K8s is implying (and it’s how the article sets it up) as a cluster. This is a big difference from running a solo instance on bare metal, in a VM, or in a container. That’s the point I was making to the parent comment.
To go up a level (comment), running Postgres in K8s doesn’t really get you much that you can’t also get from a VM (I’m thinking mainly about migration and setup). After that, the benefits come from running a cluster, which K8s can make easier to orchestrate over bare metal. But that’s a different architecture entirely.
and the answer is we will definitely be running DBs in clustered mode in the future. its not really a debate its an eventuality.
without clusters you lose on reliability and maintenance QOL improvements. without clusters its very hard to upgrade systems effectively leaving systems to stagnate and decay both in performance (Hard/Software improvements aka kernel updates or inbternal DB improvements) and reliability.
Or will they be on something more purpose-built, either designed from the start to handle storage more flexibly at a higher level? Or conversely something more specific and lower-level to extract maximum performance for their particular storage patterns?
In this case, you should be asking “will we all be running databases in clustered mode in the future?”
I think that answer still up for debate.