Live data from Hacker News

Upgrading Uber's MySQL Fleet

uber.com

31–40 of 215 posts

Re: Upgrading Uber's MySQL Fleet

#31
post #13

So satisfying to do a huge upgrade like this and then see the actual proof in the pudding with all the reduced latencies and query times.

Yeah some numbers caught my attention like ~94% reduction in overall database lock time. And to think they never have to worry about VACUUM. Ahh the peace.

As somebody who has always used MySQL, but always been told that I should be using Postgres, I'd love to understand what the issues with VACUUM are, and what I should be aware of when potentially switching databases?

Re: Upgrading Uber's MySQL Fleet

#32
post #13

Earlier quoted context omitted.

Yeah some numbers caught my attention like ~94% reduction in overall database lock time. And to think they never have to worry about VACUUM. Ahh the peace.

Yeah, until vacuum is gone, i'm not touching postgres. So many bad experiences with our use cases over the decades. I guess most people don't have our uses, but i'm thinking Uber does.

Maybe just vacuum much more aggressively? Also there have been a lot of changes to the vacuuming and auto vacuuming process these last few years, you can pretty much forget about it.

Re: Upgrading Uber's MySQL Fleet

#33

I can tell from a mile away that this is written by ChatGPT / Claude, at least partially. "This distinction played a crucial role in our upgrade planning and execution strategy." "Navigating Challenges in the MySQL Upgrade Journey" "Finally, minimizing manual intervention during the upgrade process was crucial."

[deleted]

Re: Upgrading Uber's MySQL Fleet

#34
post #19

[flagged]

I had a similar reaction when reading https://engineeringblog.yelp.com/2024/10/migrating-from-post...

everyone is praising postgres and shitting on mysql, until performance matters. then, when all these big tech companies turn to mysql, the postgres fanboys cry in unison.

Re: Upgrading Uber's MySQL Fleet

#37

I can tell from a mile away that this is written by ChatGPT / Claude, at least partially. "This distinction played a crucial role in our upgrade planning and execution strategy." "Navigating Challenges in the MySQL Upgrade Journey" "Finally, minimizing manual intervention during the upgrade process was crucial."

> I can tell from a mile away that this is written by ChatGPT / Claude, at least partially.

Whilst it may smell of ChatGPT/Claude, I think the answer is actually simpler.

Look at the authors of the blog, search LinkedIn. They are all based in India, mostly Bangalore.

It is therefore more likely to be Indian English.

To be absolutely clear, for absolute avoidance of doubt:

This is NOT intended a racist comment. Indians clearly speak English fluently. But the style and flow of English is different. Just like it is for US English, Australian English or any other English. I am not remotely saying one English is better than another !

If, like me, you have spent many hours on the phone to Bangalore call-centres, you will recognise many of the stylistic patterns present in the blog text.

Re: Upgrading Uber's MySQL Fleet

#38
post #19

Earlier quoted context omitted.

I had a similar reaction when reading https://engineeringblog.yelp.com/2024/10/migrating-from-post...

I get the urge to standardize infrastructure but... wow. After reading the whole thing, I get why they thought it was worth doing, but you'd think they'd just hire a Postgres guy or two. Especially when they looked at the missing features, this feels like a downgrade...

In big companies they never just "hire a guy or two"; the bus factor would be atrocious in this case, not to mention vacations and such. The minimum unit of hiring is one team, about five people five or take. So the difference they are looking at is either hiring a team of Postgres people or forcing everyone on one existing team to learn Postgres deeply. From this perspective, standardizing on infrastructure makes more sense now.

Re: Upgrading Uber's MySQL Fleet

#39
post #13

Earlier quoted context omitted.

Yeah some numbers caught my attention like ~94% reduction in overall database lock time. And to think they never have to worry about VACUUM. Ahh the peace.

As somebody who has always used MySQL, but always been told that I should be using Postgres, I'd love to understand what the issues with VACUUM are, and what I should be aware of when potentially switching databases?

VACUUM and VACUUM FULL (and/or with ANALYZE) can lock tables for a very long time, especially when the table is large. Incantation may also require 2x the space for the table being operated on. In short: it's slow.

Re: Upgrading Uber's MySQL Fleet

#40

I can tell from a mile away that this is written by ChatGPT / Claude, at least partially. "This distinction played a crucial role in our upgrade planning and execution strategy." "Navigating Challenges in the MySQL Upgrade Journey" "Finally, minimizing manual intervention during the upgrade process was crucial."

> I can tell from a mile away that this is written by ChatGPT / Claude, at least partially. Whilst it may smell of ChatGPT/Claude, I think the answer is actually simpler. Look at the authors of the blog, search LinkedIn. They are all based in India, mostly Bangalore. It is therefore more likely to be Indian English. To be absolutely clear, for absolute avoidance of doubt: This is NOT intended a racist comment. Indian…

I agree (I've posted a similar comment in the past and collected a handful of downvotes). Much like ChatGPT, you tend to see a slight over use of more formal and obscure words and a tone that tends to feel like the topic being discussed is being given just a touch too much focus or dedication relative to the grand scheme of things. It is hard to fully describe, more of a "you know it when you see it".
Post reply on HN