opinion
Jan 27, 20265 mins
In May of 2025, MySQL celebrated its 30th anniversary. Not many technology projects go strong for three decades, let alone at the level of use that MySQL enjoys. MySQL is listed at #2 on the DB-Engines ranking, and it is listed as the most deployed relational database by technology installation tracker 6sense.
Yet for all its use, MySQL is seen as taking a back seat to PostgreSQL. Checking the Stack Overflow Developer Survey for 2025, 55.6% of developers use PostgreSQL compared to 40.5% that use MySQL. And …
opinion
Jan 27, 20265 mins
In May of 2025, MySQL celebrated its 30th anniversary. Not many technology projects go strong for three decades, let alone at the level of use that MySQL enjoys. MySQL is listed at #2 on the DB-Engines ranking, and it is listed as the most deployed relational database by technology installation tracker 6sense.
Yet for all its use, MySQL is seen as taking a back seat to PostgreSQL. Checking the Stack Overflow Developer Survey for 2025, 55.6% of developers use PostgreSQL compared to 40.5% that use MySQL. And when you look at the most admired technologies, PostgreSQL is at 46.5% while MySQL languishes at 20.5%. Whereas developers clearly think highly of PostgreSQL, they do not view MySQL as positively.
Both databases are excellent options. PostgreSQL is a reliable, scalable, and functionality-rich database, but it can be beyond the needs of simple application projects. MySQL is fast to deploy, easy to use, and both scalable and effective when implemented in the right way. But PostgreSQL has fans and supporters where MySQL does not.
This is not a question of age. PostgreSQL is older than MySQL, as development work started in 1986, though the first version of PostgreSQL wasn’t released until 1995. What is different is that the open source community is committed to PostgreSQL and celebrates the development and diversity taking place. The sheer number of companies and contributors around PostgreSQL makes it easier to adopt.
In comparison, the MySQL community is … quiet. Although Oracle has been a great steward for MySQL since the company acquired Sun in 2010, the open source MySQL Community Edition has received less love and attention than the paid MySQL Enterprise Edition or cloud versions, at least in terms of adding innovative new features.
For example, while Oracle’s MySQL HeatWave boasts innovations like vector search, which is essential for AI projects, MySQL Community Edition lacks this capability. Although MySQL Community Edition can store vector data, it cannot perform an index-based search or approximate nearest neighbour search for that data.
In other open source communities, we have seen a “big shock” that led to change. For example, when Redis changed its software license to be “source available,” the community created Valkey as an alternative. When HashiCorp changed its license for Terraform, it led to the creation of OpenTofu. These projects joined open source foundations and saw an increase in the number of companies that provided contributions, support, and maintenance around the code.
Having avoided such a big shock to the system, the MySQL community has been in stasis for years, continuing with the status quo. Yet in an industry where technology companies are like sharks, always moving forward to avoid death at the hands of the competition, this stasis is detrimental to the community and to the project as a whole.
However, a big shock may have finally arrived. The loss of many Oracle staffers has impacted the speed of MySQL development. Looking at the number of bug fixes released in each quarterly update, the number of issues fixed has dropped to a third of what it was previously. Compared to Q1 2025 (65 fixes) and Q2 2025 (again, 65 fixes), MySQL 8.4.7 saw just 21 bug fixes released. While straight bug numbers are not a perfectly representative metric, the drop itself does show how much emphasis has been taken off MySQL.
In response, companies that are behind MySQL are coming together. Rather than continuing with things as they are, these companies recognize that developing a future path for MySQL is essential. What this will lead to will depend on decisions outside the community. Will this act as a spur for a fork of MySQL that has community support, similar to PostgreSQL? Or will this lead to MySQL moving away from the control of a single vendor, as has been the case since it was founded?
Whatever happens, MySQL as an open source database is still a valid and viable option for developers today. MySQL has a huge community around it, and there is a lot of passion around what the future holds for the database. The challenge is how to direct that passion and get MySQL back to where it should be. MySQL is a great database that makes it easy to implement and run applications, and it is a useful option where PostgreSQL is not a good fit or overkill for an application deployment.
Now is the time to get involved in the events being organized by the MySQL community, to join the Foundation for MySQL Slack channel, and to help build that future for the community as a whole, and to get excited about the future for MySQL again.
—
New Tech Forum*** provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all ***inquiries to doug_dineley@foundryco.com.

by Laura Czajkowski
Contributor
Laura Czajkowski is Director of Community at Percona, an open source database company that works around multiple databases including MySQL, PostgreSQL, MongoDB, Valkey, and others. Laura’s background is in building and engaging with effective developer communities around open source and data. Prior to joining Percona, Laura led developer and community work with companies including Vonage, Couchbase, MongoDB, and Canonical.