Upgrading Uber's MySQL Fleet

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...

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.

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.

There'd be less of that if there weren't a feeling that MySQL is the high-grade free hit that Oracle uses to get you hooked on their low-grade crap.

It's been 15 years since oracle acquired MySQL. I agree that you should always be prudent with Oracle but that's a long time...

Uber also famously migrated from postgres to MySQL, so they have used both!

Tbf, either can be made to be fast, or slow. MySQL used to have a huge advantage for range queries due to its clustering index (assuming you have designed a schema to exploit that capability), but as time has gone on that gap has narrowed [0] (despite the title, it's not just about inserts). My own benchmarks for strictly read-only queries have also borne that out.

The biggest difference, IMO, is if you _aren't_ aware of the clustering index, and so design your schema in a way that is suboptimal. For example, given a table with orders or something similar, with a PK of `(user_id, created_at)`, a query like `SELECT... FROM... WHERE user_id = ? ORDER BY created_at DESC LIMIT 1` can be quite fast in MySQL. With a monotonic integer as the PK, and a secondary index on those two columns, it can still be quite fast, depending on insert order. If however you invert the PK to `(created_at, user_id)`, while MySQL 8+ will still be able to use the index, it's not nearly as efficient – in my tests, I saw query speed go from 0.1 msec --> 10 msec.

In contrast, while there is a small difference in Postgres with all of those differences, it's just not that big of a difference, since it stores tuples in a heap. Again, in my tests, query speed went from 0.1 msec --> 0.7 msec. This is a point query, of course; with range queries (`WHERE created_at < ...`) Postgres suffered more, jumping up to ~25 - 50 msec.

[0]: http://smalldatum.blogspot.com/2024/09/mysql-and-postgres-vs...

use mariadb instead of mysql.