Comment

Comment by uutangohotel

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?

No comments yet

Be the first to share your thoughts.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton