MariaDB Plugins Beyond C++: What the Community Told Us

A few weeks ago, we asked a simple question:

Which language would you use to write MariaDB plugins?

The question related to MDEV-40189 (Support plugins written in various languages), an idea we introduced earlier this summer to lower the barrier to MariaDB plugin development by supporting languages other than C and C++.

The poll is now closed, and 2,090 people voted.

And the results are interesting.

Python and Rust lead, but there is no single winner

Python takes first place with 21%, closely followed by Rust with 19%.

This is not really surprising.

Python has a huge developer community and is often the first choice when the goal is to prototype something quickly and make it accessible to more developers.

Rust is interesting for a different reason. It is much closer to the kind of systems programming environment where MariaDB plugins live today, while offering a much stronger memory-safety model than C or C++. For some types of plugins, Rust could therefore be a very natural candidate.

But I think the most interesting result is actually what happens after Python and Rust.

There is no dominant language.

Go gets 12%, JavaScript 11%, TypeScript 9%, and Lua 8% (I skip the “Other” section on purpose, as it’s mostly SQL injection attempts).

Even JavaScript and TypeScript together represent around 20% of the votes, essentially the same level of interest as Python or Rust.

So perhaps the question is not simply:

“Which language should MariaDB support?”

Maybe it should be:

“How can we make the MariaDB plugin API accessible from several languages?”

Only 4% said they would simply keep using C++

Another number caught my attention.

Only 82 people out of 2,090 — about 4% — selected “I plan to keep using C++.”

Of course, this poll should not be treated as a scientific survey of every MariaDB developer. People interested in alternative programming languages were probably more likely to answer a poll specifically about alternative languages; more than 23k people saw the poll.

And C++ is not going anywhere.

MariaDB Server itself is written primarily in C and C++, and native plugins will remain extremely important, particularly when performance, low-level server integration or direct access to server internals is required.

But the result still sends a useful signal. There seems to be real interest in having another way to extend MariaDB. That’s exactly what MDEV-40189 is trying to explore.

MDEV-40189 is still open and, at the time of writing, unassigned. It proposes exploring support for MariaDB plugins written in languages other than C/C++, potentially using SWIG or a dedicated “foreign language support” plugin.

SWIG is a software development tool that connects programs written in C and C++ with a variety of high-level programming language

We would really appreciate help from the community here. You do not need to arrive with a complete implementation. A small proof of concept would already be extremely useful.

This is open-source development: we can discuss the idea, experiment, learn what works and what doesn’t, and improve the design together.

A little reflection

In MySQL (starting in 2018), they used GraalVM with the MLE Language Plugin (libpolyglot) to provide the possibility to write stored programs in your preferred language. It ended up supporting only JS in MySQL HeatWave and MySQL Enterprise Edition.

Then Percona decided to also implement JS support in Percona Server using V8. I’m not sure about the status of this component, which doesn’t seem to have been updated in a year.

V8 is Google’s open source high-performance JavaScript and WebAssembly engine, written in C++

For MariaDB Server, I think the most interesting architecture today would be to embed a WebAssembly runtime, with Wasmtime as my first candidate, rather than embedding a JVM-like polyglot environment or V8 which is very complicated to use and compile.

Wasmtime is open source, designed explicitly for embedding, and exposes a C API plus a C++ wrapper, so integrating it into the MariaDB Server codebase is realistic. More importantly, WebAssembly gives you a natural sandbox boundary: extensions don’t automatically get arbitrary memory, filesystem, network, or server-process access unless MariaDB explicitly exposes those capabilities.

Additionally, the really interesting part is the WebAssembly Component Model + WIT. WIT is a language-neutral interface definition system, and components can be produced from several languages. The official Component Model documentation currently includes examples for C/C++, C#, Go, JavaScript, Python, Rust, TinyGo, MoonBit, and more.