GitLab has finally called time on its support for MySQL, after losing patience with the venerable but cranky open source database.

As this issue in GitLab’s forums says, “Over the years MySQL has been nothing but a pain in the ass” while its support for modern SQL features is “limited” .

A more measured statement said MySQL support will cease as of GitLab 12.1, which is due later this month. It went on to list a number of limitations in its use of PostgreSQL, including having to use hacks to increase limits on columns, which could lead to the database refusing to store data.

These meant it had ended up creating “a lot of MySQL specific code”, and “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 meant doubling up on its CI, as it had to run its test suites twice – one for each:  “Removing support for MySQL reduces the time for our CI jobs, and reduces the costs.”

Consequently, “Where we wanted to utilize specific performance and reliability capabilities unique to a backend, we had to instead choose the lowest common denominator.”

GitLab first declared its intention to ditch MySQL in 2017, and said most of its customers had already moved to PostgreSQL, according to Usage Ping data. 

“We’ve seen a steady migration to PostgreSQL and recently had less than 1200 GitLab instances reporting their usage of MySQL. Of those still using MySQL the majority were using 11.0 or earlier,” the firm said.

“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.”

Details on how to migrate are here.