Since this is just a PR announcement by a third-party posted on an official PostgreSQL page: what is the difference between this and established PostgreSQL operators by Zalando and CrunchyData?
It seems like the big difference is that it uses the standard PostgreSQL Docker images and doesn't bundle together as many things as Zalando or Crunchy Data. They'd likely argue that makes it easier to learn and a smaller surface area for attacks or things to go wrong.
Crunchy Data includes lots of add-ons like pgBouncer, pgAdmin 4, pgMonitor, and a bunch more. That might be a lot for someone that just wants a simple replicated PostgreSQL setup.
But I don't know much about Kubegress. It's repository has only 67 commits and 3 contributors so it's not as widely used as something like Crunchy Data or Zalando which have thousands of commits and hundreds of contributors. Likewise, Crunchy Data and Zalando both have 2,000+ stars compared to 387 for Kubegress.
That's not necessarily a sign of quality and part of that could be that Kubegress had a bunch of development before being open-sourced, that being later to the game makes it harder to build community, and that creating something simple might not require as many commits since you're creating something simple.
I love this sort of thing. Something I appreciate is looking through the resulting YAML config at the best practices and rich experience by the team that wrote it.
It reminds me of receiving "golden images" from vendors with a precisely best-practice install and configuration of their software.
I've interacted with the kubegres creator and maintainer in the past and it was a good experience, wishing them luck giving Zalando and Crunchy operators a run for their money.
generally hope 'self hosting your DB' becomes a spectrum rather than a choice to use or not use RDS
it's frustrating that you can't use something like timescaledb on a paas (i.e. that timescale needs to manage their own instances to operate their business).
not sure kube is the cheapest or safest way to run a DB, but there should be something platform-like for hosting persistent data
Does Kubegres works with any TCP proxy, and if does - is there any recommendations which one?
Running ingress via Load Balancer is quite costly option in cloud context. At the moment is seems that nodeport is only realistic alternative.
These things aren't magical. You will have some downtime because your connection to the database will be interrupted (after all, it just died, no way around it), and depending on your configuration, you may lose some data; you need at least one synchronous replica to ensure that no data is lost on an uncontrolled failover. If you have a two-node "cluster" with synchronous replication, then either one going down will stop writes on the master, so you would need at least three nodes.
Mind you, no clustered system can provide you zero downtime and zero data loss without essentially the same constraints. If you have an unplanned failure, there's going to be a blip somewhere. It's up to the rest of the system to recover from it gracefully.
When configuring any kind of cluster involving data (especially one that's supposed to recover automatically from faults), make sure you understand how it behaves and adjust for your application, because quite often the default configurations might accept some data loss in unplanned failover or conflict scenarios.
Logical for AWS or logical for their customers? Frankly probably not either way. RDS excels due to it deep integration with AWS proprietory block store. If you want your data in PVs RDS dose not offer enough, if you want you data on RDS then K8S scheduling wouldn't add much.
