Reading the Room: What Europe’s MySQL Community Is Really Saying
FOSDEM was exciting from a MariaDB perspective for many reasons this year. For this blog, let me concentrate on one aspect: The discussions at what was called the “Summit for MySQL Community, Europe”, hosted by Percona on Monday 2 Feb 2026 at the Marriott Grand Place in central Brussels.
We got the answer key – the “Oracle examiner’s solution”
With many of my former MySQL AB colleagues leaving Oracle over the years, I certainly had a fairly good picture of what has been happening at Oracle since I left the company shortly after the acquisition of Sun Microsystems was completed in 2009. But never with this clarity, and never directly from the horse’s mouth, if by “horse” one means top MySQL Engineering leadership: Tomas Ulin and Geir Høydalsvik. With Geir, I never had the pleasure to work, but I worked over many years with Tomas at MySQL AB, and I respect him deeply.
Tomas and Geir are both amongst the people laid off by Oracle, and they confirmed most of our suspicions of Oracle’s attitude to MySQL, but not all. Some turned out to be misconceptions: Oracle was never intentionally holding back on MySQL to make it “bad”.
The feeling of “I should have understood that” came from being explained the reasoning behind Oracle’s decisions. They are rational, but from an Oracle shareholder perspective, albeit not from a MySQL user, developer, or community perspective.
The main reason behind most of the Oracle decisions that appear counter-productive from a pre-Oracle perspective on MySQL have to do with policies in a company the size of Oracle. It makes sense to follow a common policy across product lines. Those policies often don’t match the needs of Open Source. As an example, Geir pointed out that closing the MySQL bug database, which caused Red Hat to swap MySQL for MariaDB, is one such policy – which he and Tomas fought in vain. Tomas pointed out that the open community discussions typical to Open Source development (and upheld as best we can by MariaDB Foundation) never were allowed by Oracle company policy. Le Fred’s safe harbour statement as the first slide of his presentation was a tiny case in point and got a chuckle out of the Brussels audience.
Listening to Tomas and other ex MySQL AB colleagues laid off in the past few months made me appreciate what a good job they had done for MySQL during all those years, in a company with a corporate DNA very different from that of MySQL. Nonetheless, it was sad to hear Geir describe that the MySQL Server work force has been reduced from 96 developers at peak time to now only 35, most of which work on OCI (Oracle Cloud Infrastructure) and not on MySQL Community Server.
Geir’s comment about Oracle’s last-Thursday declaration of “reinforced commitment behind MySQL” being “too little, too late” is probably better informed than that of most other people.
This news is fundamentally unsettling for the MySQL user community
The overall sentiment I sensed in the room was a combination of frustration, sense of urgency, and fear of fragmentation.
Frustration: MySQL at Oracle is in Maintenance Mode
The frustration comes from the consensus feeling that MySQL at Oracle is in maintenance mode. LeFred, Oracle’s MySQL Community Manager, did as well as he humanly could to portray Oracle’s actions as community-friendly. Yet facts do speak against a good future of MySQL within Oracle, given the reduction in work force and the loss of MySQL expertise.
Naturally, who wants to use a product which isn’t being actively, properly, lovingly developed?
Sense of Urgency: MySQL is still better than PostgreSQL
The sense of urgency comes from another consensus opinion, that MySQL beats PostgreSQL from a performance, scalability, and ease of use perspective. The MySQL community needs to quickly fight back and showcase MySQL’s technical excellence, since PostgreSQL has captured the narrative and the youth. Canonical (Mykola Marzhan and Mohamed Wadie Nsiri) had a great presentation scoring higher points for MySQL than PostgreSQL on several items
- using threads instead of processes (MySQL is more lightweight, easier to scale #connections),
- faster asynchronous io in MySQL,
- better MVCC with ease of maintenance (no need for vacuuming in MySQL),
- better High Availabilty in MySQL (easier to setup, better integration)
while acknowledging PostgreSQL’s strengths in write performance, in tooling and ecosystem breadth.
Fear of fragmentation: Diverging incentives
The fear of fragmentation comes from the fact that community interests in the room don’t inherently pull in one direction. The few remaining Oracle people want to claim that MySQL is being taken properly care of by Oracle. Percona has a lot of healthy MySQL business focused around services, not putting huge development resources behind Percona Server. MariaDB Foundation argues that MariaDB is the future of MySQL. Amazon AWS does business on PostgreSQL, MySQL, and MariaDB all in parallel. TiDB developers want to promote TiDB. Booking and other users of MySQL mainly want to avoid the cost of migrating off a product that works well, but still dislike a product in maintenance mode.
The dilemma is that a joint solution – whatever it may be – requires lots of resources and coordination. Putting in those resources requires a self interest, a considerable financial self interest.
That said – the joint interest is to not throw away the jewel that MySQL is, to not waste all the resources put into the systems, the skills, the careers built around a technically sound product.
Enter MariaDB Foundation
After the insightful and fair presentations by Vadim Tkachenko and Peter Zaitsev of Percona as well as Geir Høydalsvik formerly of Oracle, I asked Vadim if I could say a couple of words. This is roughly what I said (or at least meant to say):
I’m Kaj, Chairman of the MariaDB Foundation, and I don’t know how welcome we are by the community in this room, based on our mantra of “MariaDB is the future of MySQL”. That said, we genuinely want to contribute to your initiative on your terms. My point is that in a certain sense, MySQL really lives on in a concrete way in MariaDB. It provides an answer to most of the concerns raised by Vadim, Peter, and Geir.
I saw many friendly faces and nods in the audience. In fact, the subsequent presentation by Canonical favourably mentioned MariaDB several times, underlining the point that we have every opportunity to make the overall pie grow bigger.

How MariaDB Foundation was received
All in all, I sensed MariaDB to be taken seriously within the group, being part of the MySQL family. I had to leave the room before the interesting afternoon sessions around true action items to be taken by the group. The group will continue its conversations – and we intend to participate constructively.
Conclusion: What this summit revealed
Three things became clear to me:
- The MySQL community is searching for credible long-term stewardship.
- PostgreSQL is speeding ahead for other reasons than technology leadership.
- MariaDB is already addressing many of the issues the group is bringing forth.
From the MariaDB Foundation’s perspective, the message is simple: we will continue investing in open governance, long-term stewardship and deep MySQL compatibility — regardless of what others choose to do.
Agreed on almost everything you said, but “closing the MySQL bug database”? That part of MySQL is still alive, and even my all-time favorite bug is there: https://bugs.mysql.com/bug.php?id=2.
The bug database is there in the sense that you can report bugs and the reported bugs (unless they are security bugs) are kept in the database. Similarly Oracle allows contribution to MySQL, but gives zero feedback on the development and whether they will actually handle the contribution or not, the same applies to bugs.
Well, here’s to the new year. Up until recently, we were using MySQL for our regression tests on GitHub. We’ve recently moved to MariaDB 10.6 for the time being, and will dovetail in various flavors of MariaDB as part of our release cadence moving forward.
Before Oracle, I was on board with MySQL. I went from thinking Microsoft Access was fine until I started working with real data and waiting half the night for imports of just millions of rows to finish. Then, I moved to Microsoft SQL Server, and that was actually pretty awesome. Their GUI in Microsoft SQL Server 2000 had a lot of enterprise management features that I would love to see in MariaDB. However, once I got to MySQL in 2001 and now MariaDB land, I was cooked.
I just love it’s designed in from the beginning observability, storage engines, replication support, galera, you name it. It’s been a 25 year adventure, a good one too. Yes, there have been hiccups, but when I look at how PostgreSQL has to be managed, and database storage has to be upgraded (with downtime), I just shudder to think that it’s actually usable in enterprise settings.
At the same time, I acknowledge that the write performance of MariaDB is not too sexy, with a storage array that could do 2M+ IOPS and 23 GB/second, I could barely push over 500 MB/second and needed more… However, with that said, not going anywhere.
Cary on team. Have a good year! Oh, and Bug #2. Legendary.