Eight reasons not to use MySQL

When I was in charge of managing a technical consulting firm, I heard some reasons not to use MySQL. While many of the reasons are misleading, there are some very good reasons not to use MySQL. Of course, the actual situation will vary depending on the environment, but in each case, I feel that rejecting any database technology should be based on reasonable reasons, rather than on the advice of some jaded database administrator (DBA). To achieve this, I have listed eight reasons for not using MySQL in this article.

First, the rationale for not using a technology and the rationale for using it are fundamentally different. Often, the argument against something is more noticeable. We may need a few reasons to really use this technology, but one reason will stop us. The choice of software is such a decision, there is only one reason is not enough to induce us to make affirmative decisions, but a full negative reason will negate many positive factors.

While there is a long list of relational database management systems (RDBMS) that we can choose from, I limit the comparisons to a few of the most commonly used products. Although there are few comprehensive comparisons, there are many technical comparisons. Here, we are only concerned with "formal" reasons.

MySQL uses the GPL

The most important reason is first. This is not suitable for the GNU General public License and should not be a choice of database technology. Obviously, GPL licenses are positive for many environments, but for other environments, GPL software is hopeless. Under these circumstances, even PostgreSQL's BSD license is still too "open", so a business license would be more appropriate.

MySQL does not use the GPL

In some cases, MySQL is charged, so the GPL may not serve these situations well. If you want to sell this database license with your own project, you must use a similar license for your project, or you will need to purchase a business license. If this factor changes the way your software is sold, you need to deal with the additional burdens that must be caused by having to support multiple versions or configurations of MySQL (which increases the cost of end users), or the unreasonable impact of MySQL usage. In these cases, some software distributors may prefer to adopt other products, such as the PostgreSQL of BSD licenses.

Integration with the existing environment

I know that large IT companies will have Oracle and Sybase unit software usage rights (Site License), and many Ms-sql server proprietary licenses (specific License). Among these companies, this ms-sql is largely the result of ignorant staff in various departments who do not know that they have paid to purchase the site license of other databases. In this environment, it is unwise to join MySQL (or another database) if the DBA already has too many environments to deal with. In the presence of existing databases, if a common platform is maintained, it is obvious that the burden of maintenance will be reduced. Further, if the company already has a license to use a private system, the main reason for using MySQL is not there.

Maturity of the product

By comparison, Oracle will celebrate the 30 anniversary of its first product release in 2009, when MySQL's first product was released less than half of Oracle's time. On its own, Microsoft SQL Server was only a few years ahead of MySQL, but its first release was based on Sybase, which was 6 years earlier than SQL Server. As for other famous Open-source databases, the first release of the PostgreSQL in 2009 has been 20 years. While MySQL is not the latest database on the market, there are many older, more stable alternatives-and for many people, that is enough. To be fair, in my opinion this is not a very good reason to oppose the use of MySQL, but at the same time I was forced to tell a conservative IT manager who would choose a platform for mission-critical applications to make a decision based on this reason would be wrong.