MariaDB Server has long supported a flexible plugin architecture. Plugins allow developers to extend server functionality in areas such as data types, auditing, storage engines, information schema tables, and more.

Today, MariaDB Server plugins are typically developed in C or C++, like the server’s codebase. At least for a while

Even with the current plugin-writing approach, familiarity with MariaDB internals is beneficial because it enables you to do things you otherwise cannot. But it is not required.

A new development idea, MDEV-40189: Support plugins written in various languages, explores whether MariaDB Server could make plugin development accessible from additional programming languages.

The idea is to investigate how plugins could be written in languages such as Rust, Python, JavaScript, or Lua, while still integrating cleanly with the existing MariaDB plugin infrastructure.

Supporting additional implementation languages could make MariaDB plugin development more approachable for a wider range of developers and use cases.

For example, it could make it easier to prototype new plugin ideas, experiment with integrations, or evaluate safer and more ergonomic development models in languages such as Rust. It could also help developers who are already productive in languages like Python, JavaScript, or Lua explore MariaDB Server extensibility without needing to begin directly with C or C++.

This would not replace existing native plugin development. C and C++ remain important for low-level, performance-sensitive server functionality. Instead, this work would explore whether MariaDB can offer additional paths for plugin authors where appropriate.

The MDEV suggests investigating SWIG as a possible approach to making the MariaDB plugin API available across multiple programming languages. This could provide a common foundation for generating bindings or wrappers that allow plugin authors to interact with the required MariaDB APIs from languages other than C or C++.

SWIG usually stands for Simplified Wrapper and Interface Generator.

Another possible approach, especially for a Rust prototype, would be to use bindgen.

bindgen is a tool that generates Rust bindings for C or C++ APIs, most commonly from C header files.

While SWIG focuses on generating bindings for multiple programming languages, bindgen is more specifically used to generate Rust FFI bindings from C header files. This could make it possible to expose selected parts of the MariaDB plugin API to Rust code, allowing a plugin author to call MariaDB server APIs from a Rust implementation while keeping the low-level ABI boundary explicit.

Using bindgen would leave important design questions open. Generated Rust bindings are usually close to the original C API, which means that memory ownership, pointer lifetimes, callbacks, error handling, and server lifecycle integration would still need to be carefully designed. In practice, a useful Rust plugin interface would probably require a safe wrapper layer over the generated bindings, rather than exposing the raw bindings directly to plugin authors.

So bindgen could be a good candidate for Rust-oriented plugins, while SWIG may remain interesting for a broader multi-language binding strategy.

For interpreted languages, there is also a separate question: how should the language runtime be embedded, managed, or isolated? One possible direction would be a dedicated plugin type for “foreign language support,” responsible for managing the runtime and exposing a controlled interface to plugins written in that language.

A useful reference point is MySQL’s JavaScript stored-program support, which integrates a JavaScript runtime through the Multilingual Engine (MLE) and GraalVM. In that model, developers can write stored functions and procedures in JavaScript, while the database server executes the code through GraalVM’s managed runtime. Although MariaDB plugins are a different extension point than stored programs, the MySQL approach is relevant because it illustrates one way a database server can embed a modern language runtime, expose database-facing APIs, and manage execution, type conversion, privileges, and runtime behavior within the server process.

Another useful comparison point is Percona Server for MySQL, which has introduced experimental support for JavaScript stored programs using the Google V8 engine. As with the MySQL/GraalVM example, this is not the same as MariaDB plugin development, but it is relevant because it shows another practical approach to bringing a modern language runtime into a MySQL-compatible server.

Together, these examples suggest that there are at least two separate problems to solve. The first is how to expose the MariaDB plugin API to code written in another language. This is where an approach such as SWIG could be useful: it could help generate bindings or wrappers, allowing plugin authors to call the required MariaDB APIs from languages other than C or C++. The second problem is how that foreign-language code is executed inside, or alongside, the server. For JavaScript, for example, that could mean embedding an engine such as V8. A broader polyglot approach could point toward something like GraalVM, while Python or Lua would raise their own questions about runtime integration. In other words, SWIG would not replace GraalVM, V8, or another runtime; it would address a different layer of the design. Even with V8 as a JavaScript engine, MariaDB would still need a clean and safe way to export the plugin API to JavaScript.

WebAssembly is another model worth considering. A WASM-based approach could provide a language-neutral execution target, allowing plugins or plugin logic to be written in any language that can compile to WASM. It could also offer a clearer sandboxing boundary than directly embedding a full language runtime in the server process. At the same time, a WASM approach would raise its own questions around host APIs, memory management, performance, packaging, debugging, and how much of the MariaDB plugin API could realistically be exposed through a WASM boundary.

There are several technical questions to consider:

• How should MariaDB plugin APIs be exposed safely and consistently to other languages?
• Which plugin type would make the best first proof of concept?
• How should memory ownership, error handling, and lifecycle management be handled?
• What are the performance and security implications of embedding interpreters?
• Would Rust, Python, JavaScript, Lua, or another language be the most suitable first target?
• Could SWIG provide a practical path, or would a more language-specific implementation be preferable?

A useful first step could be a small proof of concept focused on a narrow plugin type and a single target language. This would help evaluate the feasibility of the approach before expanding the scope.

For example, an initial prototype could demonstrate:

• A minimal plugin written in Rust
• A small Python-based plugin loaded through an embedded interpreter
• SWIG-generated bindings for a limited subset of the plugin API
• A basic “foreign language support” plugin that manages a language runtime
• A design proposal comparing possible approaches and trade-offs

The goal of such an experiment would not be to solve every use case immediately, but to clarify the architecture, limitations, and next steps.

This is an early-stage idea with room for exploration. If you are interested in MariaDB internals, plugin systems, language bindings, embedded interpreters, Rust, Python, JavaScript, Lua, or SWIG, this could be an interesting technical challenge to take on.

Do you have an implementation idea? Would you approach this with generated bindings, a dedicated language runtime plugin, a Rust-first prototype, or an entirely different design?

Take a look at MDEV-40189, share your thoughts, or try a small proof of concept. Practical experiments and design proposals would be valuable input to deciding whether and how MariaDB Server could support plugins written in multiple programming languages.

Thank you for using MariaDB Server.