<story><title>Running Databases on Kubernetes</title><url>https://questdb.io/blog/databases-on-k8s/</url></story><parent_chain></parent_chain><comment><author>_skel</author><text>I don&amp;#x27;t think the upsides are worth all the work.&lt;p&gt;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?&lt;p&gt;Plus, &amp;quot;herds not pets&amp;quot; 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&amp;#x27;t handle being run like ephemeral cattle. So why not just keep using your static environment?&lt;p&gt;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&amp;#x27;t &lt;i&gt;really&lt;/i&gt; suck, it&amp;#x27;s probably not worth migrating. It would take a lot of time and introduce significant new risks and operational complexity without a compensating payoff.</text></comment>
<story><title>Running Databases on Kubernetes</title><url>https://questdb.io/blog/databases-on-k8s/</url></story><parent_chain></parent_chain><comment><author>mdasen</author><text>I&amp;#x27;ve been quite happy with CloudNativePG on k8s. It was simple for me to set up on a k8s cluster with one primary and two replicas, if the primary box goes down another instance becomes primary, deal with connection pooling, and simple to have backups go to a cloud object store. The alternative is dealing with all the replication manually, making sure that your leader election and failover work, making sure you can stand up new PG instances and get things replicated to the new instance, having a service that is checking the health of the database to trigger a failover, etc. It&amp;#x27;s certainly not impossible or anything like that, but CloudNativePG has been pretty easy. K8s isn&amp;#x27;t perfect or anything, but it&amp;#x27;s been a pretty nice experience for me.&lt;p&gt;I&amp;#x27;ve tried other Postgres operators and been disappointed and it did require a little learning, but it&amp;#x27;s not like getting replication, Patroni, etcd, PGBouncer, HAProxy, and pgBackRest all running for a high-availability Postgres deployment is easy and wouldn&amp;#x27;t require learning.&lt;p&gt;As the author says, &amp;quot;[k8s&amp;#x27;s] operator model allows end users to programmatically manage their workloads by writing code against the core k8s APIs to automatically perform tasks that would previously have to be done manually.&amp;quot; To me, that&amp;#x27;s the benefit. The operator can handle tasks like adding a replica or failing over the primary to one of the replicas. I could presumably do some of that with other tools on bare metal&amp;#x2F;VMs (I can always shell-script things), but I&amp;#x27;ve had a good experience with CloudNativePG&amp;#x27;s operator. Likewise, as the author says, making day-2 operations easier is a big thing.&lt;p&gt;K8s does have some annoying amount of complexity, but it&amp;#x27;s been nice overall.</text></comment>