Hacker News Reader

Comment by qeternity | Hacker News Reader

We recently rolled out Patroni on k8s and it definitely does not “just work”. I suppose once you get it up and running, there’s some truth to that, but it’s one of the most hostile pieces of software I’ve come across. This isn’t a complaint, after all, Zalando don’t owe me anything. But the documentation, the project structure, the contributors...it all reveals very clearly that this is really just some internal tooling that they happen to make public, as opposed to a first-class OSS project. Unfortunately it’s also the best Postgres HA system out there, but it’s truly a massive PITA to get setup and it’s extremely opinionated about things that it doesn’t need to be.

View on HN

Patroni was openly developed from day 0. The repo was created in early July 2015, but before that it was living as the fork of Compose Governor.

The Spilo docker container which packages PostgreSQL + Patroni was also always publicly available from the first day. I agree, the Spilo is a bit opinionated due to the way how it is used at Zalando.

These two projects have quite a long history and originally weren't even targeted to be deployed on K8s because back in 2015 K8s wasn't absolutely suited for running stateful workloads.

The most opinionated one is Zalando Postgres-Operator, and yes, first it was the internal tooling and was solving our specific problems. Now I would also argue that with such an amount of external contributors it already became a way more general solution.

After all, Patroni is so general, that we call it a template for PostgreSQL HA. You can take it and build something that you need/want without relying on Spilo and Zalando Postgres-Operator. Speaking of Patroni@K8s, there are already two very nice examples: Crunchy Data PostgreSQL Operator and StackGres are both relying on Patroni for running PostgreSQL HA on K8s.

Hi Cyber - yes I know it has a very active community, and you and I have interacted on github before. But I find this response very similar to github: it’s a template, so build whatever you like with it. That’s not what most people want, and that kind of a reply reinforces my comment. I don’t use React because I want a template for for building a reactive application. I use it because it does all the things I don’t want to have to be concerned with. Like I said, I don’t think any project needs defense. I thank you all for the work you’ve done. But it is not the easiest bit of kit nor the most helpful/inclusive community.

I recently have been working on setting up a HA Postgres Cluster on K8's... its for a pretty small DB use case and not knowing much about the world of Postgres and Databases I ended up using the Crunchy Postgres Operator which amazingly did all of the work for me... (I honestly don't know much about Patroni other then it manages the switchover to replicas during a failure)... anyway I'd recommend the Crunchy Operator...

As a side note, we've found that it takes quite a while for the initial pgBackRest job to run (like 8 minutes) which seems like a lot for an empty DB, but we aren't using SSDs

I'm curious, did you use Patroni directly on Kubernetes or use Zalando's Postgres Operator [1] (based on Patroni)? [1] https://github.com/zalando/postgres-operator

After spending quite a bit of time with the operator early on, along with the KubeDB operator (super easy to use, but definitely not production ready) we settled on some patroni helm charts.

Reply on news.ycombinator.com