While MySQL isn't the best db, and does have many flaws, it's asinine to say that other solutions are wholly better. Everything has a set of limitations, so just because something like Postgres doesn't have this specific limitation doesn't mean it doesn't have others. It also may be more worth it to work around the limitations of MySQL than to migrate all data to another database.
Keep in mind that Postgresql wasn't as in vogue when Github was first built, and most or all of the NoSQL solutions you're thinking of didn't even exist. Up until 2 years ago, they were running Rails 2.3, and then is when they moved to Rails 3 (Rails 4 had been out a year at that point). I am very assured that Github is very careful about their technology choices and not quick to chase trends, given the importance of their application.
Not by my recollection, and most ways of looking at trends seem to suggest the same: (unfortunately many don't go back that far, but let you see some trends)
And if you read carefully through their post, and the comments, and the commentary on pgsql-hackers, you'd see that:
1) it was an engineering decision based on their particular situation and use case (as it should be)
2) that use case may be pretty specific and/or unique, and not well suited for Postgres (which is fine)
3) they don't explain what all their tradeoffs are, just the ones they're making arguments against (which makes the post much less useful than it could be)
I would not take that blog post as a general "MySQL is better than Postgres" argument. It really needed more info on what they're doing, why they're doing it that way, and what tradeoffs they were willing to make (speed vs. data integrity, etc.).
