Skip to content
GitLab
Next
    • GitLab: the DevOps platform
    • Explore GitLab
    • Install GitLab
    • How GitLab compares
    • Get started
    • GitLab docs
    • GitLab Learn
  • Pricing
  • Talk to an expert
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    Projects Groups Topics Snippets
  • Register
  • Sign in
  • GitLab FOSS GitLab FOSS
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
    • Locked files
  • Issues 23
    • Issues 23
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 0
    • Merge requests 0
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Container Registry
    • Terraform modules
    • Model experiments
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • Code review
    • Insights
    • Issue
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • GitLab.orgGitLab.org
  • GitLab FOSSGitLab FOSS
  • Issues
  • #51173
Closed
Open
Issue created Sep 06, 2018 by Yorick Peterse@yorickpeterseContributor

Consider removing support for MySQL

Result

We have agreed to remove support for MySQL at some point. Discussion about when should move to https://gitlab.com/gitlab-org/gitlab-ce/issues/52442

Background

Over the years MySQL has been nothing but a pain in the ass. It's support for modern SQL features is limited, GitLab's internal knowledge of it is limited, and for many new features we need to introduce branches in the code to support both PostgreSQL and MySQL. We should start coming up with a plan to drop support for MySQL entirely, roughly following these steps:

  1. Start gathering all cases where MySQL is limiting us
  2. Figure out how many paying customers we have that use MySQL, and how much we earn from this. Having 500 customers use it but pay us €5 wouldn't really be worth the effort of supporting MySQL. On the other hand, 2 customers paying €500 000 is a different story.
  3. Determine when and for how long we want to deprecate MySQL
  4. Come up with a plan to migrate the paying customers off MySQL
  5. Decide which major version will drop MySQL support

Arguments For

Costs of ongoing support

  • Slowing down velocity? (note @brodock - can you provide some more detail here?)
  • Others?

Places where MySQL already is not supported

  • Geo
  • Disaster Recover
  • Helm Charts

Issues

This is a list of all MRs / features where MySQL was somehow limiting us, with a short summary of the problem. This list should be updated over time as more issues appear:

  • https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/21499: CI wants to store data as JSON, using PostgreSQL's jsonb type to store the data more efficiently. MySQL/Rails has no support for this, requiring either hacks or the use of text.
  • In various MRs we started introducing indexed binary columns, often containing a SHA value. MySQL doesn't support arbitrary length indexes on binary types, so we have to use a hack to index only the first 20 bytes on MySQL
  • https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/6896: adds a composite index that includes a binary column. This required extending the above hack to support this for MySQL
  • Nested groups can not work on MySQL as it doesn't support CTEs, requiring if mysql? checks in a variety of places
  • MySQL requires a variety of hacks to increase limits on various columns, and the right character encoding. Without this, users can run into issues where it refuses to store data. Example: https://gitlab.com/gitlab-org/gitlab-ce/issues/49583
  • Cycle analytics uses an almost completely different implementation for MySQL. On PostgreSQL we use CTEs, but on MySQL we use temporary tables (which will not scale at all).
  • We cannot leverage PostgreSQL partitioning easily because we cannot use triggers to stay compatible with MySQL https://gitlab.com/gitlab-org/gitlab-ce/issues/51173#note_103352064

Related / Previous discussions

  • https://gitlab.com/gitlab-org/gitlab-ce/issues/43252: this talks about dropping PG 9.2 support, but there is also a short discussion on MySQL (https://gitlab.com/gitlab-org/gitlab-ce/issues/43252#note_60352182).

cc @gl-database @sytses @JobV

Edited Apr 04, 2019 by Kenny Johnston
Assignee
Assign to
Time tracking