Hacker News Reader

Comment by pinaraf | Hacker News Reader

So much work where there are many other solutions out there that don't have that limitation : PostgreSQL, several NoSQL databases...

View on HN

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.

Exactly this.

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.

Really?

To me postgres and MySQL have been in a similar spot for 10 years at least. MySQL with a few more users but not massive.

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)

http://www.indeed.com/jobtrends/q-postgresql-q-mysql.html

http://db-engines.com/en/ranking_trend

http://readwrite.com/2013/09/10/postresql-hits-93-new-levels...

I guess I forget that 70% of the web is PHP and 95% of PHP is MySQL, so I tend to not get a fair picture of life.

It appears that MySQL has held the 10x postgre spot for a long time, at least in search trends..

Literally right at this moment there's a post on the front page from Postgres detailing the valid technical reasons they lost Uber to MySQL.

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

Other systems with their own sets of limitations...

Many people are tied to MySQL for other reasons, it might be too costly investment to switch, etc...

Reply on news.ycombinator.com