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?

> As always, my book, Mastering Emacs is 31% off for the next week to celebrate the release also.

Eventually, Mastering Emacs will be free!

f*** around and find out

oops accidental surveillance machine

The wall around viewing an item is too heavy handed IMO.

Use verified email (or magic link) to auth for posting and actions (validating). The posts themselves should be public.

You’d also get some SEO opportunities from more public pages.

Is there any reason why I'd want this release instead of waiting for 26.04?

I can’t say I’m surprised; but I am disappointed.

Too little too late?

Would you mind expanding on the usage of enums for the feature flags table? Why not use a boolean?