It can go wrong. I had a horrible experience with StackGres. I read a lot of positive things about CloudNativePG though. I can see where people with startups are coming from not wanting to manage database plumbing so they can focus on real business tasks. I think that's fine as long as there is a path to self-host after some growth. I might do some event-sourcing myself so that databases are effectively materialized views easy to add and remove.

Hi, StackGres founder here.

We're constantly striving to improve the user experience and the quality of StackGres. Would you mind sharing some feedback as to what made your experience not good with it?

Did you join the Slack Community (https://slack.stackgres.io/) to ask if you were facing some trouble? It always helps, even if it is just by sharing your troubles.

(If you'd like to share feedback and do so privately, please DM on the Slack Community)

Your feedback will be much appreciated.

I did try slack. Maybe the problem is it was launched much too early. A certificate expiry issue caught me out because there wasn't an automatic process on this version to roll them over. Ironically a single database instance would have been much much more stable. I upgraded but this didn't bring up the database, restoring through the portal failed, so I had to create a new PG cluster to get my site up and I never ended up recovering the data as the process was very tedious involving PVCs rather than just pointing to my bucket. The ratio of open to closed issues on the repo is much worse than CNPG so I would simply start there.

Thank you for your feedback. I'm trying to extract possible improvement actions from your comment, and here are my thoughts.

That certificate expiry issue was unfortunate, but was resolved (if I'm not mistaken) a couple of years ago.

StackGres is just a control plane, your database is as stable as a standalone one. StackGres itself may fail and it won't affect your database, it's not on the data plane. Indeed, it has a feature to "pause it" if you need to perform some manual operations (otherwise everything is automated).

There are procedures to reconstruct a database from PVC. It's arguably tedious, but should be much simpler than running a Postgres pod without the help of an operator like StackGres.

As for the ratio of issues: most of the issues that we get are feature and/or extensions requests, and certainly we can't tackle them all. Most, if not all, outstanding issues are addressed within a reasonable time frame. Is there any particular issue that would itch you that is open? I'd be happy to personally review it. Yet, there are as of today more than 2K closed issues, I won't call that a small number.

I'd also weight the importance of issues, like the split brain that CNPG suffers [1] and that apparently won't even be solved. StackGres relies instead on the trusted and reputed Patroni, which is known NOT to risk split brains that could lead to severe data loss.

[1]: https://github.com/cloudnative-pg/cloudnative-pg/discussions...

I think people with startups just don't care. I had an interview with a startup the other day, and the interviewer said they were considering using v0 for their front-end. I really want to be wrong here, but so far it feels like all those startups are there to just take VC money for themselves and die.

That article is good if you don't care about uptime or incident recovery time.

Yugabyte is the best open source postgres for HA.

Once you have reason to care about that, then you should also be able to afford to hire people that can sort it out for you.

Not really. Maybe for consumer. But there are many kinds of b2b infrastructure businesses that I can build and launch myself where I wouldn't want to expose myself to risk of day-long outages (for either reputational or as competitive disadvantage of having no HA story), such as anything to do with payment gateways, API gateways, AI proxies or other AI infrastructure - anything where client services would experience critical outages if your service goes down... Lots of these businesses are started without VC investment or big money from day 1.

Luckily now with solutions like Yugabyte, we can achieve enterprise-grade HA without high cost or high maintenance complexity.

I'm not familiar with their products but it seems they had a four hour incident a few months ago:

https://status.yugabyte.cloud/history

You should not run a payment gateway on an inexperienced team. Start with something with lesser risk and then introduce the team to things like load balancers, keepalived, clustering and so on over time.

An hour of downtime is a lot once HA is something to invest in, and the first thing you need to do when there's an incident is to tell your customers what you're doing about it and the second thing they want to know is whether it will happen again. Since I don't know how Yugabyte works I'm not sure about the degree of lock-in, but preferably you should have an incident process where you at minute ten or so of downtime boot load balancing with a customer facing message at another infra provider and update DNS records, then start to rebuild the system there in parallel with the main incident response.