Why do Atlassian engineers complain and pushback about MySQL

Rich Kucera March 30, 2017

How can you read Uber's writeup and support and recommend postgres more each release of every product?

https://eng.uber.com/mysql-migration/

Seems like every release notes there is a section advocating how limited and terrible MySQL is and switching to postgres,  for all products.

In some cases,  MySQL isn't even supported,  such as in Data Center product.

What does Atlassian know that Uber doesn't?

1 answer

3 votes
crf
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
March 30, 2017

Disclaimer: This is my personal opinion and reflects much of my past experience with MySql (roughly 15 years or so).  It is not an official Atlassian position, and as I no longer work on JIRA Data Center, I can't really speak to what it going on or what their plans might be for future support of any database.

I'll just call out a few specific points:

  1. What's better for one application is not always better for others.  Applications can have semantics that preferentially tune to specific databases at the cost of performance on others.  Tuning an application universally is Hard™.
  2. MySql has several quirks that make it a poor choice for developing on if you are trying to support other databases as well.  In particular, it automatically converts types for you in many cases, whereas most databases require you to be explicit when you're comparing things that rightfully should require a type cast (to prove you're aware of the mismatch and happy with the performance consequence).  This means that if you develop on MySql, you're more likely to create bugs because it allows you to do bad things that other databases would have called you out on.
  3. MySql has several quirks around locking and constraints that make it more difficult to support in conjunction with other databases.  In particular:
    1. It frequently kills the "wrong" transaction in a deadlock (that is, it is just as likely to kill one that has done a lot of work already instead of the transaction that's only done one statement), meaning that when there is a conflict, you're more likely to lose something important.
    2. It does constraint validation per-row instead of per-statement, meaning that if you're doing something like updating the index numbers for a list of items, you have to include an ORDER BY clause.  It's weird to need to specify an ORDER BY on an UPDATE, and no other database supports that syntax (because they do constraint validation properly and therefore have no need of it).
    3. It has historically had extremely poor performance on certain constructs that other databases don't seem to have trouble with.  Subqueries and LEFT JOIN... WHERE joined.col IS NULL come to mind.  That can often be rewritten as a WHERE NOT EXISTS (subquery) instead, but not always, and it has turned out to be painful on many occasions.
  4. While every database brings its own quirks to the table (Oracle's treatment of empty strings as NULL comes to mind), market demand has to be weighed against that.  The enterprise market is vastly dominated by Oracle and SQLServer.  When we surveyed potential customers for JDC, neither MySql nor Postgres had a respectable showing. However, we have historically used Postgres in Cloud, so we were motivated to continue using it for development and most of our testing.  MySql had no such excuse to be made on its behalf.
  5. Uber clearly had different goal in mind.  Much of the article you've shared talks about scaling the database to thousands of connections and the overhead costs of doing this with separate processes instead of threads, something that is almost completely irrelevant for JIRA.  Our context switching concerns are generally more in JIRA itself, not the database.  The fact that we offload most searching to Lucene instead of the database and use caching to avoid hitting the database at all when we can makes for a very, very different access model compared to what Uber is discussing.

In short, we don't have to know something that Uber doesn't to come to a different decision.  We are not the same company, and we have different requirements and considerations than they do.

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events