By Steinar Gunderson December 5, 2021
Today was my last day at Oracle, and thus also in the MySQL team.
When a decision comes to switch workplaces, there’s always the question of “why”, but that question always has multiple answers, and perhaps the simplest one is that I found another opportunity, and and as a whole, it was obvious it was time to move on when that arrived.
But it doesn’t really explain why I did go looking for that somewhere else in the first place. The reasons for that are again complex, and it’s not possible to reduce to a single thing. But nevertheless, let me point out something that I’ve been saying both internally and externally for the last five years (although never on a stage—which explains why I’ve been staying away from stages talking about MySQL): *MySQL is a pretty poor database, and you should strongly consider using Postgres instead.*1
Coming to MySQL was like stepping into a parallel universe, where there were lots of people genuinely believing that MySQL was a state-of-the-art product. At the same time, I was attending orientation and told how the optimizer worked internally, and I genuinely needed shock pauses to take in how primitive nearly everything was. It felt bizarre, but I guess you soon get used to it. In a sense, it didn’t bother me that much; lots of bad code means there’s plenty of room for opportunity for improvement, and management was strongly supportive of large refactors. More jarring were the people who insisted everything was OK (it seems most MySQL users and developers don’t really use other databases); even obviously crazy things like the executor, where everything was one big lump and everything interacted with everything else2, was hailed as “efficient” (it wasn’t).
Don’t get me wrong; I am genuinely proud of the work I have been doing, and MySQL 8.0 (with its ever-increasing minor version number) is a much better product than 5.7 was—and it will continue to improve. But there is only so much you can do; the changes others and I have been doing take the MySQL optimizer towards a fairly standard early-2000s design with some nice tweaks, but that’s also where it ends. (Someone called it “catching up, one decade at a time”, and I’m not sure if it was meant positively or negatively, but I thought a bit of it as a badge of honor.) In the end, there’s just not enough resources that I could see it turn into a competitive product, no matter how internal company communications tried to spin that Oracle is filled with geniuses and WE ARE WINNING IN THE CLOUD. And that’s probably fine (and again, not really why I quit); if you’re using MySQL and it works for you, sure, go ahead. But perhaps consider taking a look at the other side of that fence at some point, past the “OMG vacuum” memes.
My new role will be in the Google Chrome team. It was probably about time; my T-shirt collection was getting a bit worn.
1 Don’t believe for a second that MariaDB is any better. Monty and his merry men left because they were unhappy about the new governance, not because they suddenly woke up one day and realized what a royal mess they had created in the code.
2 For instance, the sorter literally had to care whether its input came from a table scan or a range scan, because there was no modularity. Anything that wasn’t either of those two, including joins, required great contortions. Full outer joins were simply impossible to execute in the given design without rewriting the query (MySQL still doesn’t support them, but at least now it’s not hampered by the old we-can-do-left-deep-plans-only design). And don’t even get me started on the “slice” system, which is perhaps the single craziest design I’ve ever seen in any real-world software.