4 ms·

20 years ago people said the same thing about running DBs on virtual machines. Now almost all databases are run on VMs

mbreese 5y ago
But that’s really not a great comparison, is it? Running on a VM is much more like running on a plain physical node. Running on K8s implies a whole new level of management overhead, that just isn’t there on a single node system. 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.
- jatone 5y ago
  containers are actually a really good fit for dbs. they do one thing and one thing only and for a really really long time without many changes. 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.
  - morelisp 5y ago
    The question isn't whether DBs will be running in clusters - they all pretty much do, or can - but will those clusters be orchestrated by something first designed for dynamic scaling of stateless services, treating all nodes as varying-sized pools of otherwise mostly-homogeneous hyperconverged compute/storage? Or, how much are you willing to pay in $/performance/dev time to force them into such infrastructure? 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?
- gizdan 5y ago
  > Running on a VM is much more like running on a plain physical node. 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.
  - mbreese 5y ago
    But that’s not the difference. Any single process can run in a container without much issue. I think volume storage isn’t a solved issue yet, but it is better. 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.
Keyframe 5y ago
Now almost all databases are run on VMs now, that's a bit of a stretch, no?
morelisp 5y ago
> Now almost all databases are run on VMs And now almost all databases (meaning running instances, not software artifacts) are way slower than necessary and lie about durability.

But that’s really not a great comparison, is it? Running on a VM is much more like running on a plain physical node. Running on K8s implies a whole new level of management overhead, that just isn’t there on a single node system. 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.

jatone 5y ago
containers are actually a really good fit for dbs. they do one thing and one thing only and for a really really long time without many changes. 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.
- morelisp 5y ago
  The question isn't whether DBs will be running in clusters - they all pretty much do, or can - but will those clusters be orchestrated by something first designed for dynamic scaling of stateless services, treating all nodes as varying-sized pools of otherwise mostly-homogeneous hyperconverged compute/storage? Or, how much are you willing to pay in $/performance/dev time to force them into such infrastructure? 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?
gizdan 5y ago
> Running on a VM is much more like running on a plain physical node. 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.
- mbreese 5y ago
  But that’s not the difference. Any single process can run in a container without much issue. I think volume storage isn’t a solved issue yet, but it is better. 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.

Keyframe 5y ago

Now almost all databases are run on VMs now, that's a bit of a stretch, no?

morelisp 5y ago

> Now almost all databases are run on VMs And now almost all databases (meaning running instances, not software artifacts) are way slower than necessary and lie about durability.