GitLab: with the release of version 12.1 we stop supporting MySQL
- Transfer
Now we’ll explain why, starting with version 12.1, GitLab will no longer support MySQL.
In July 2017, GitLab warned that it would stop supporting MySQL . So, with the release of 12.1, the preparation period for this will end, and we will not support MySQL anymore . The decision is not easy, and we would like to share our arguments.
MySQL was not very suitable for our use case
There are many successful implementations of MySQL, however, in our case, it did not quite fit. Compared to PostgreSQL, MySQL has a number of limitations , which led to problems with PostgreSQL when trying to adapt MySQL. Here is a short list of restrictions:
- With MySQL it was not possible to effectively support nested groups
- There are also restrictions on the fields that we bypass using various tricks, and as a result, mysql may simply not save data
- MySQL will not add a column type
TEXTunless you specify the length parameter - MySQL does not support partial indexes
- This set of restrictions already created several points (including Geo), on which we did not support MySQL anyway.
He slowed us down
To bypass the "sick" places, we wrote specific code for MySQL , which in fact resulted in the maintenance of yet another database subsystem, and in fact - doubled complexity in code code merges . Support for such code also led to overhead, which resulted in slower release speeds.
Separately, it is worth mentioning our CI system, which ran tests twice, thus stopping MySQL support, we will reduce testing time and infrastructure costs. Costs, it must be said, are significant , not paid back by a small number of users on MySQL.
We have lost the advantages of both server parts.
Supporting both server parts (PostgreSQL and MySQL), we could not fully use either of them. Where I would like to use the performance and reliability features of any of them, I had to reduce everything to the lowest common denominator. Example ( not the only one ): we wanted to use LATERAL JOINPostgreSQL to optimize events in the control panel, but we did not succeed because we used MySQL .
Almost all of our PostgreSQL customers
Focusing on Usage Ping data , we clearly saw that the vast majority of clients have already switched to PostgreSQL. The trend is quite stable, for example, recently for 1200 installations with MySQL there were about 110,000 installations on PostgreSQL.
We are sure that our users who use MySQL can simply change the database by switching to PostgreSQL when upgrading to gitlab 12.1 or later.
By the way, we ourselves do not work with MySQL, which means that we did not encounter problems BEFORE our users.
Need help with migration?
If you are one of these users, please read the migration documents for guidance on migrating from MySQL to PostgreSQL .