The 2026 equivalent of 2016's "Why Uber Engineering Switched from Postgres to MySQL" ! https://www.uber.com/us/en/blog/postgres-to-mysql-migration/

Is Quack, the DuckDB client-server protocol, something that could have helped them with the scaling problems they encountered?

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?

Feels off that only 5 months ago the company just migrated to DuckDB only to now move to something else.

Who did the growth estimation of the data? This looks like an example of bad planning.

I'm surprised at this. That is a lot of engineering effort without revealing why they chose they own format and chose to query it via Trino.

Interestingly, it seems that a data lake is the hot new thing to build in house. Hell, we did it too. If you don't mind, I wrote up exactly what these new data lakes tend to look like: https://telemetrymachine.com/blog/the-new-state-of-the-art-i...

The git repo [0] has a lot more of the technical details.

[0] https://github.com/PostHog/hoglake

This idiotic churn used to be restricted to front end devs and backend folks were spared. Thanks for Agents now every part of the stack is going to be in constant churn thanks to resume builders. At no point in the article did you get a sense they have a handle on what their problem is and why a certain technology and architecture would be a better fit. Just try it out, churn out, try it out.

This post is pointless. Tells us how it went, show performance numbers, show benefits, resource usage, ease of use, etc.

after 3 months, how we switched back to forked clickhouse.