Starting with SonarQube v7.9 we will no longer support MySQL with any edition of SonarQube. A few months ago, starting with the SonarQube 6.7.x LTS, we took two steps to ensure customer success. First, we stopped MySQL support for DCE deployments. Additionally, we began recommending PostgreSQL (Postgres) for all commercial environments, especially deployments with large instances or ones that could become large over time. These actions have resulted in a significant reduction in the number of large deployment issues reported by our community.
The reasons for no longer supporting MySQL are straightforward. At SonarSource, we target operational excellence with our products and we do not want our users to face scaling issues as their dataset grows over time. To that end, the following considerations guided our decision:
We want SonarQube to scale and provide very good performance to our users
In our experiences with the 7.x releases of SonarQube, along with knowledge gained building out SonarCloud, we observed that SonarQube can be engineered to run faster and scale better, but it requires significant, focused development in the specific database platform.
While we do have the internal competencies and bandwidth to accomplish this for Postgres, Microsoft SQL Server and Oracle; it would be a significant challenge for us to achieve this for MySQL.
We decided to focus on product excellence and that requires us to end MySQL support in order to bring our Community a SonarQube offering that provides a consistent user experience.
Ultimately, we feel that taking this step now results in the best, long-term success for our users and without compromising future SonarQube features and functionality. We didn’t make this decision lightly and spent considerable time evaluating all the factors involved. We understand migrating to another database involves time and effort so we’re here to provide the help and tools to make your migration successful.
Starting with SonarQube 7.9, we’ll support Oracle, Microsoft SQL Server and PostgreSQL. Postgres is free and open-source while Oracle and Microsoft do charge for their tools. We’re investing resources into PostgreSQL to ensure our users experience SonarQube compatibility with a high level of performance on a free-to-use database.
We created an open-source tool to help you move data from MySQL to one of the other supported databases. This dedicated tool helps SonarQube users that are on version [6.7 LTS - 7.8] to move their instance out of MySQL to a supported database. Get the migration details here.
Hello,
Thanks for creating the detailed guide.
If we are using a commercial edition, will it be necessary to request a new license, as obviously the JDBC URL will change?
What is the impact to start using sonarqube 7.9 on a new empty database ?
Can say that i find the documentation for database migration tool complete by the way.
Is it possible to upgrade/db conversion from 6.7.7 to 7.9.X (latest LTS version) with postgresql when the database is currently MySQL or do you need to upgrade to 7.8 + MySQL first, then do db conversion/upgrade to 7.9 + postgresql?
Welcome to the community. I’ve moved your topic here from the 7.9 announcement, since it has a higher affinity with this topic.
The OP in this thread includes this:
So to answer your question, you can migrate DBs on 6.7, then jump to 7.9(.1) or you can move to 7.8 on MySQL, migrate DBs, and then upgrade to 7.9.1. Since there are fewer steps in the first scenario it seems like it would be easiest to handle the DB upgrade first.
If I’m migrating a 7.8 installation from MySQL to Oracle, do I really need to do a separate 7.9 deployment towards Oracle first (as the documentation hints, but does not state) or can I migrate into an empty Oracle schema?
You will need to start up a 7.8 instance aginst Oracle to populate the schema, and then initiate the migration using mysql-migrator, and then upgrade to 7.9
While I understand the reasoning, I still find the EOL of MySQL disappointing.
Not everyone needs the fastest, latest, greatest in order to do useful work. (Hey, Harry Dresden still drives a VW bug, right? ) If I’m trying to introduce SonarQube into our corporate workplace, getting it going and useful with a minimum of hassle, is worth FAR MORE to us than whether it’s fast as it can possibly be.
If we start using it big-time, then it’s worth connecting to Oracle, or setting up postgres, etc. But I think the idea of putting barriers (i.e. no MySQL) in the way of possible new customers is short-sighted.
And possibly… and I mean this in the most respectful way, given what you’ve all created… could this be a bit self-centered? Is this really what is best for all your existing and potential customers? Or is this about what you want if you were the customer(s)? I just ask that you think about that angle.
Also, I think it would be helpful to specify that the last version of SonarQube that supports MySQL is 7.7. At least that way, if someone wants to TRY SonarQube (like me) on the QT, and has MySQL available, they’ll know what to do.
The announcement implies that MySQL wanna-be’s should try 7.8, but that does not appear to be correct. I did get it working with 7.7. (Although the doc has a small bug, it says “create an empty schema”, but it doesn’t say that the schema must be named “sonar”.)
I do not agree with your reasoning for dropping MySQL support. You’re focusing on SQL Server performance, and dropping a well-established and widely used open source database?
In the not too distant past (~1-2 years ago) your documentation actually recommended MySQL as the preferred database. It’s disappointing that I will be forced to now decide to A) not upgrade, B) deploy a new database and deal with migration, or C) look for a SonarQube alternative.
) If I’m trying to introduce SonarQube into our corporate workplace, getting it going and useful with a minimum of hassle, is worth FAR MORE to us than whether it’s fast as it can possibly be.