I would have appreciated more technical details with methodologies and explicit failures observed. Oh and a human voice would be nice for a change.

> Customers ran more complex queries than we expected

Did the queries change after DuckDB was introduced? Did they do a study of query patterns that could have anticipated this ahead of time?

> Predicting CPU and memory for a specific query was even harder.

What attempts / methodologies were used to try this? What was hard? What failed?

> We'd rather have contributed to the existing community and helped it grow. But we couldn't land changes as fast as we needed, so we ended up carrying patches in a fork

This isn't a BAD approach per se. IME it's common (and necessary) for the large scale users of a platform to maintain a fork for their needs and work with the community and the maintainers to upstream changes when/if the community is ready to accept. That's called influencing. On the other hand, if you toss of a few slop grenades to the community and they reject you shouldn't be surprised. (Not suggesting that's what happening here but the defeatest conclusion may imply it?)

> Missing reconnects and managing TTLs and idle connections at scale is hard

Wonder if they tried pgdog?