Last week, Oracle invited MariaDB Foundation to give a presentation at Oracle’s MySQL Contributor Summit 2026. I had the opportunity to participate remotely and speak about MariaDB’s role within the broader MySQL ecosystem.

First of all, I would like to thank Heather VanCura, VP Community Engagement at Oracle, and Jason Wilcox, SVP Data Services at Oracle, for the invitation and for creating a space where these discussions could happen openly and constructively.

The presentation itself is available here on YouTube. At just over 17 minutes, it is reasonably compact viewing for anyone interested in the current state — and possible future direction — of the MySQL ecosystem.

MySQL + MariaDB > PostgreSQL

From my perspective, one underlying conclusion became increasingly clear: One underlying driver behind the gathering is the broader competitive landscape.

PostgreSQL continues to gain developer mindshare rapidly. In that situation, unnecessary fragmentation inside the MySQL ecosystem weakens everyone.

Cooperation where it makes practical sense can strengthen the ecosystem as a whole.

This is one reason why discussions around interoperability, plugin architectures and ecosystem conventions matter.

The MySQL family still possesses major strengths around operational simplicity, replication, HA, pragmatic deployment models and broad operational familiarity across the industry. Those strengths should not be casually discarded.

Cognitive Dissonance

At one level, this was simply a technical conference session among many others. At another level, however, I believe the invitation itself says something important about the current state of the MySQL ecosystem — and perhaps also about where it may be heading.

MariaDB Foundation has publicly positioned MariaDB as both the natural successor to MySQL and the natural replacement for MySQL.

We have also, at times, argued that MySQL 8.0 itself can meaningfully be viewed as a fork — depending on one’s frame of reference and which aspects of the original MySQL philosophy one considers most central.

These are not consensus views within the MySQL world. And yet Oracle invited us to participate. I think that deserves recognition.

It reflects a willingness to tolerate a certain amount of cognitive dissonance: different organisations may have partially overlapping goals, partially conflicting goals, different governance models, different commercial interests, and still find value in discussing interoperability, extensibility and ecosystem continuity together.

Reading the Room

Earlier this year, in “Reading the Room: What Europe’s MySQL Community Is Really Saying”, I reflected on a growing concern I encountered repeatedly in conversations across the European MySQL world: uncertainty about the future direction of MySQL, concerns about continuity, and increasing interest in ecosystem-level cooperation.

The discussions at the Contributor Summit reinforced that impression.

One recurring theme was interoperability: how to avoid unnecessary fragmentation and preserve practical migration paths, operational familiarity and ecosystem trust.

Another was extensibility — especially the challenge of reducing time-to-market for plugins and making ecosystem innovation easier to share.

Plugin ABI

This is where discussions around plugin ABI compatibility become genuinely interesting — an area strongly highlighted during the Summit by former MySQL AB colleague and long-time Oracle VP Tomas Ulin, now with VillageSQL. A properly architected plugin ABI could make practical ecosystem innovation easier to share.

The MySQL ecosystem today consists of several different implementations, forks and surrounding projects. MariaDB is one of them. Percona Server is another. VillageSQL and OurSQL are examples of attempts to think about this broader reality in a constructive and ecosystem-oriented way.

The important point is that the ecosystem remains viable, interoperable and attractive to users and developers.

Forking is Hard

Forking is hard.

Maintaining long-term compatibility is hard. Preserving operational familiarity while independently evolving a code base over fifteen years is hard. Building extensibility frameworks that multiple parties can realistically adopt is hard.

Monty Widenius recently reflected on some of these questions in his blog post “The concepts of forking”. It is worth reading for anyone interested in the practical realities of long-term open source stewardship.

Discussions Around Functionality Already Present in MariaDB

One interesting aspect of the Summit discussions was that many of the topics presented as future-facing priorities for the MySQL ecosystem are areas where MariaDB already has significant practical experience. A good overview of what’s been happening in MariaDB, particularly from a MySQL ecosystem perspective, is Monty’s blog  “Celebrating 15 years of MariaDB”.

Among other things, MariaDB-specific functionality includes: 

• vector search,
• Oracle compatibility mode,
• system-versioned tables,
• InnoDB-based binlog,
• alternative storage engines,
• AI-oriented functionality,
• and various extensibility approaches.

During the Summit, MariaDB Foundation also publicly mentioned our MariaDB Skills initiative for AI-assisted database work: https://github.com/MariaDB/skills. The discussions around MCP servers versus AI skills were particularly interesting, because they highlighted how rapidly AI-related tooling is evolving around databases and developer workflows.

There was also visible interest around interoperability questions at surprisingly practical levels. During the summary session, long-time MySQL community member Simon Mudd raised a question about syntactic differences between MySQL and MariaDB and whether some of them are unnecessarily divergent. My answer was essentially that there historically has not been much cooperation in such areas — but perhaps that may gradually begin to evolve.

Constructive Coexistence

MariaDB Foundation participated in the Summit in a consciously constructive spirit.

That same spirit has also characterised recent discussions with people such as Jignesh Shah at AWS, Vadim Tkachenko and Peter Zaitsev at Percona, and others thinking seriously about the future structure of the MySQL ecosystem.

What matters is whether coexistence remains constructive, whether interoperability remains possible, and whether users retain confidence that the broader MySQL ecosystem remains alive, innovative and future-oriented.

During the Summit, Heather VanCura quoted the saying “A rising tide lifts all boats” — a formulation that also strongly resonates with the ecosystem-oriented thinking Jignesh Shah has repeatedly emphasised in discussions around interoperability and cooperation.

It is a phrase worth remembering.