It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Why do Atlassian engineers complain and pushback about MySQL

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

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 Mar 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
Community showcase
Posted in Jira Core

How to manage many similar workflows?

I have multiple projects that use variations of the same base workflow. The variations depend on the requirements of the project or issue type. The variations mostly come in the form of new statuses ...

2,174 views 10 4
Join discussion

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you