3 ms·

Your data is in a disk. Threat data like gold, postgres instances like cattle. More like a trick poney, actually, because you'll have to teach it a lot about w

Your data is in a disk. Threat data like gold, postgres instances like cattle. More like a trick poney, actually, because you'll have to teach it a lot about what to do with the several container lifetime hooks and states. But hey, if you really need to run your postgres instances in kubernetes (which you don't because cloud postgres instances can be fully automated) kubernetes operators are like the world's expert in poney training working for you.

withinboredom 4y ago
I suppose you've never had a misconfiguration corrupt all your data before? Yeh, it's on the disk, and it's just a program reading/writing to that disk... but even if those programs are cattle, those disks sure as hell are not.
- Tostino 4y ago
  Which is why pretty much every Postgres k8s operators includes a backup solution that is fully integrated. I much prefer to be able to treat the database instances like cattle, while the conceptual "cluster" and its associated backups should be treated as a pet, as you said.
candiddevmike 4y ago
This works well until a misconfiguration has your cattle eating gold.
- motoboi 4y ago
  Well, pets eat their weight in gold those days. Your pet, your problem. one operator, world's problem.
- LawTalkingGuy 4y ago
  In the pet model you fix the problem and patch the rest of the pets. In the cattle model you fix the problem and thaw a new herd. What's the practical difference?
eska 4y ago
Postgres is neither cattle, nor are there “instances”, because it assumes full responsibility for the data it manages. For example you can not have 2 postgres instances, each with their own locking mechanisms, check whether transactions are serializable, since they don’t know about the locks in the other instance. This is very basic stuff so I wonder whether people who argue for treating databases like web servers lack basic training in this area.
- motoboi 4y ago
  Yeah, right? You'd be amazed about what people can achieve with bash scripts and kubernetes containers. The crux of my argument is: you probably don't need postgres in kubernetes on the cloud (just use the damn cloud api to manage your database), but if for any reason you want to, manage a postgres with kubernetes it's like managing it with systemd. Way more involved, but doable. Great part is: just as vast majority of people don't write their own systemd units or postgres management scripts, they can use kubernetes operators and benefit from the open source knowledge and ecosystem.

withinboredom 4y ago

I suppose you've never had a misconfiguration corrupt all your data before? Yeh, it's on the disk, and it's just a program reading/writing to that disk... but even if those programs are cattle, those disks sure as hell are not.

Tostino 4y ago
Which is why pretty much every Postgres k8s operators includes a backup solution that is fully integrated. I much prefer to be able to treat the database instances like cattle, while the conceptual "cluster" and its associated backups should be treated as a pet, as you said.

candiddevmike 4y ago

This works well until a misconfiguration has your cattle eating gold.

motoboi 4y ago
Well, pets eat their weight in gold those days. Your pet, your problem. one operator, world's problem.
LawTalkingGuy 4y ago
In the pet model you fix the problem and patch the rest of the pets. In the cattle model you fix the problem and thaw a new herd. What's the practical difference?

eska 4y ago

Postgres is neither cattle, nor are there “instances”, because it assumes full responsibility for the data it manages. For example you can not have 2 postgres instances, each with their own locking mechanisms, check whether transactions are serializable, since they don’t know about the locks in the other instance. This is very basic stuff so I wonder whether people who argue for treating databases like web servers lack basic training in this area.

motoboi 4y ago
Yeah, right? You'd be amazed about what people can achieve with bash scripts and kubernetes containers. The crux of my argument is: you probably don't need postgres in kubernetes on the cloud (just use the damn cloud api to manage your database), but if for any reason you want to, manage a postgres with kubernetes it's like managing it with systemd. Way more involved, but doable. Great part is: just as vast majority of people don't write their own systemd units or postgres management scripts, they can use kubernetes operators and benefit from the open source knowledge and ecosystem.