In July of 2017 GitLab documented that we would be deprecating support for MySQL. Well, the 12.1 release marks the conclusion of our deprecation period and it will no longer support MySQL. It wasn't an easy decision, but we wanted to share with you why we did it.
It wasn't great for our use case
There are lots of great use cases for MySQL, our specific needs just didn't seem to be a good fit. Our use of MySQL had a number of limitations. In most cases, it wasn't as simple as adding support to MySQL, but that by bending MySQL we typically broke PostgreSQL. To name a few limitations:
- We can't support nested groups with MySQL in a performant way
- We have to use hacks to increase limits on columns and this can lead to MySQL refusing to store data
- MySQL can't add
TEXTtype column withoutlengthspecified - MySQL doesn't support partial indexes
- These limitations have already created a number of places where MySQL was already not supported (including with Geo)
It made us slower
In order to work around some of the pain points above, we ended of creating a lot of MySQL-specific code. In some cases this led to merge requests that were twice as complex because they had to support a second database backend. Creating and maintaining this code is a drain on our cycle time and velocity, and it puts a dampener on our value of iteration.
It also made us slower because our CI system would run our test suites twice, once on each backend. Removing support for MySQL reduces the time for our CI jobs, and reduces the costs. These costs ended up being considerable, and it was difficult to justify the expense with the small number of users choosing MySQL.
We couldn't take advantage of either backend
By providing support for both database backends (PostgreSQL and MySQL) we were unable to truly take advantage
of either. Where we wanted to utilize specific performance and realiability capabilities unique to a backend,
we had to instead choose the lowest common denominator. As an example (there are more), we wanted to use PostgreSQL's LATERAL JOIN for optimizing dashboards events, but couldn't because it was not available in MySQL.
Most of our customers are on PostgreSQL
Using Usage Ping data we got a clear sense that the vast majority of our customers had already moved to PostgreSQL. We've seen a steady migration to PostgreSQL and recently had less than 1200 GitLab instances reporting their usage of MySQL. At the time there were 110,000 instances using PostgreSQL. Of those still using MySQL the majority were using 11.0 or earlier.
This gave us a lot of confidence that GitLab users still on MySQL could migrate to the bundled PostgreSQL backend if they choose to upgrade to 12.1 and beyond, or remain on MySQL in older versions of GitLab.
As a side note – we don't use MySQL ourselves, and not doing so meant we weren't encountering issues BEFORE our users.
Need help migrating?
If you are one of those users, please check out our migration docs for a guide on upgrading from MySQL to PostgreSQL.
