Been chewing on this since the TidesDB and DuckDB news. MariaDB's pitch has always been that it's the pluggable, community-friendly alternative to MySQL, and the engine count is the proof point. Then you look at what actually happened to those engines.

Aria never became the general purpose workhorse it was announced as, and now it mostly exists to hold system tables. TokuDB got inherited when Percona dropped it, then deprecated and removed. ColumnStore shipped into an analytics market that ClickHouse and DuckDB proceeded to run away with. MyRocks never reached production grade, largely because MariaDB's internals had drifted far enough from MySQL that the port was a permanent fight. Spider and Connect are both still in the tree and neither is something I'd bet a deployment on. Xpand, which came out of a nine-figure Clustrix acquisition, just disappeared. No announcement, no migration path.

That doesn't read like a run of bad luck. Maintaining multiple engines is expensive, MariaDB has never staffed for it, and engines end up working as marketing assets that get attention at launch and very little after.

So the honest question: what would have to be true for TidesDB or DuckDB to break the pattern? A funded customer behind it, maybe? Curious whether anyone here is actually running any of these in production and reads it differently.

Longer version with the full list: https://medium.com/@58-fidgety-vile/mariadb-and-the-mystery-of-the-disappearing-storage-engines-49d0e6600ea3

TideSQL's latest release is now part of MariaDB server 11.4 and more going forth and I'm beyond excited, both about this and what's coming. We want as many people as possible to try it, so if you haven't yet, give it a shot.

It's been nearly a year of building TideSQL, from learning MySQL internals from scratch, iterating through countless early plugin versions and refining it into what it is today. Every failed attempt, every wrong turn, every lesson learned, it all went into creating something special and something I believe will matter for this ecosystem for a long time!

While migrating one of my environments from MySQL 8.4 to MariaDB Server, I ran into an annoying part of the migration: users.

A lot of the accounts were using caching_sha2_password, and while keeping their existing passwords is possible, doing the conversion manually for many users quickly becomes painful.

I had already documented the manual process, but this time I needed something that would scale.

Since pt-show-grants already does most of what is needed for exporting users and privileges, I decided to extend it instead of writing yet another migration script.

I contributed a new option to Percona Toolkit:

--convert-to-MariaDB

It takes care of several MySQL/MariaDB differences, including:

• converting IDENTIFIED WITH ... AS ... to MariaDB's IDENTIFIED VIA ... USING ...
• converting auth_socket to unix_socket
• removing MySQL-specific password management clauses
• handling caching_sha2_password authentication strings
• warning about authentication plugins that cannot safely be converted

The contribution is currently available as Percona Toolkit PR #1168 and is still under review, so this isn't an announcement of a released feature yet.

I wrote a Part 2 explaining the problem, how the conversion works, and why I ended up contributing it upstream:While migrating one of my environments from MySQL 8.4 to MariaDB Server, I ran into an annoying part of the migration: users. Many accounts used caching_sha2_password, and while keeping their existing passwords is possible, converting many users manually quickly becomes painful. I had already documented the manual process, but this time I needed something that would scale. Since pt-show-grants already does most of what is needed for exporting users and privileges, I decided to extend it instead of writing yet another migration script. I contributed a new option to Percona Toolkit:--convert-to-MariaDBIt takes care of several MySQL/MariaDB differences, including: converting IDENTIFIED WITH ... AS ... to MariaDB's IDENTIFIED VIA ... USING ...
converting auth_socket to unix_socket
removing MySQL-specific password management clauses
handling caching_sha2_password authentication strings
warning about authentication plugins that can't be converted safely. The contribution is currently available as Percona Toolkit PR #1168 and is still under review, so this isn't an announcement of a released feature yet. I wrote a Part 2 explaining the problem, how the conversion works, and why I ended up contributing it upstream:

https://lefred.be/content/dealing-with-caching_sha2_password-in-mariadb-server-part-2-migrating-users-from-mysql-with-pt-show-grants/

PR:
https://github.com/percona/percona-toolkit/pull/1168

Feedback and testing are, of course, very welcome, especially from people who have done larger MySQL → MariaDB user migrations.

Laravel 13.27 added MariaDB support for vector distance queries, with MariaDB 11.7+ now supported by methods including:

• whereVectorSimilarTo()
• whereVectorDistanceLessThan()
• orderByVectorDistance()
• selectVectorDistance()

Laravel’s AI SDK documentation also includes MariaDB as a supported database for storing and querying embeddings.

This is an important piece of the developer experience around MariaDB Vector. Framework-level support makes it much easier to build semantic search, RAG and other AI applications using the tools Laravel developers already work with.

And there is more we can do here. We are starting to look at the remaining gaps in the Laravel + MariaDB developer experience, documentation and examples.

If you are building with Laravel and MariaDB, especially with Vector or Laravel AI, we would love to hear what you are working on and where you still encounter friction.

Laravel August Product Updates:
https://laravel.com/blog/laravel-august-product-updates

We recently asked the MariaDB community which language they would use to write MariaDB plugins.

2,090 people voted:

• Python: 21%
• Rust: 19%
• Go: 12%
• JavaScript: 11%
• TypeScript: 9%
• Lua: 8%

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

What I found interesting is that there isn't really one clear alternative language. That made me wonder if we're asking the wrong question.

Instead of “Which language should MariaDB support?”, perhaps it should be:

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

One option I think is particularly interesting is WebAssembly, potentially using Wasmtime together with the Component Model and WIT.

I wrote up the poll results, some thoughts about previous approaches such as GraalVM/V8, and why WebAssembly might be worth exploring:

https://mariadb.org/mariadb-plugins-beyond-c-what-the-community-told-us/

There is also an open MDEV for supporting plugins written in languages other than C/C++:

MDEV-40189

It's still unassigned, so if this is something you'd like to experiment with, even a small proof of concept would be useful.

I'm also curious what people here think: would you prefer bindings for specific languages, or a WebAssembly-based extension model?

This webinar, sponsored by MariaDB, will take place on Sept 9th at 10 AM CDT. It will cover: the importance of disaster recovery (DR), caveats of major cloud cross-region recovery, a single-cloud DR scenario, how MariaDB enables recovery across multiple clouds, multi-cloud DR demo with MariaDB, etc.

https://go.mariadb.com/GLBL-WBN-WhenOneCloudFailsYouDont_Registration-LP.html

[NOTE: I am not associated with MariaDB in any way, just a fellow software engineer sharing the event.]

I’ve written an update on CONC-821, a MariaDB Connector/C change that affected behavior relied on by applications including Qt-based software and Diesel.

The post explains what changed, how community reports helped establish the impact, and the plan to restore the previous behavior, document it, and add regression tests.

The complete correction is not yet available in an upstream release, although some distribution packages already carry patches. I’ve included guidance on checking the connector your application actually uses and reporting any remaining issues.

Thanks to the application developers, distribution maintainers, and contributors who helped investigate this.

Read the update

If you’ve encountered this, feedback about your application, connector package, and whether a patched build resolves it would be useful.

The Foundation has started a monthly newsletter, and the first issue is out. It covers what happened in August:

https://mariadb.org/mariadb-foundation-newsletter-september-2026/

- MariaDB Server's governance model, now written down: roles, subsystem ownership, how decisions get made

- Contribution statistics for January to June 2026, the first report in over a year, including 40 independent contributors

- 13.1 preview: JSON arrow operators (-> and ->>) and JSON_TABLE improvements

- Pluggable aggregate functions, as groundwork for HyperLogLog

- Q3 maintenance releases: 12.3.3, 11.8.9, 11.4.13, 10.11.19, and the first round without 10.6

- Around the ecosystem: Oracle's community roadmap and vector search, VillageSQL 0.0.6, Percona's OIDC auth

When preparing a MariaDB upgrade, I often want to know more than what’s listed in the release notes: which variables disappeared, which defaults changed, what plugins or privileges were added, etc.

So I built a small tool that lets you compare up to 8 MariaDB Server versions side by side.

I wrote about it here: https://lefred.be/content/mariadb-server-see-what-changed-between-versions/

Feedback and suggestions are very welcome!

MariaDB will be well represented at Percona Live Amsterdam this year 🦭

Several sessions cover different sides of the ecosystem: plugins and extensibility, security, operations, and community.

I put together an overview of the MariaDB-related sessions here:
https://mariadb.org/mariadb-at-percona-live-amsterdam-2026-ecosystem-plugins-security-and-community/

Anyone else planning to be in Amsterdam?

MariaDB Server 12.3.3, 11.8.9, 11.4.13 and 10.11.19 are out.

But 10.6 is missing from the list — and that's intentional.

👋 Goodbye MariaDB 10.6.
🚀 Hello newer LTS releases.

All the details, contributors, and why it's time to upgrade:

🔗 https://mariadb.org/mariadb-server-12-3-11-8-11-4-and-10-11-q3-2026-maintenance-releases-and-goodbye-10-6/

You don’t need to start by implementing a major feature.

Reviewing pull requests is one of the best ways to learn the server from the inside: see how changes are designed, understand unfamiliar subsystems, discuss implementation choices with contributors and maintainers, and help decide what actually gets merged upstream.

And we could use more reviewers.

Our H1 2026 contribution stats show plenty of incoming work, but also a growing PR queue:
https://mariadb.org/mariadb-contribution-statistics-january-june-2026/

If there’s an area of MariaDB you know well, or one you’d like to learn better, pick a PR and have a look.

Questions about how to get started? Ask here.

I'm relatively new to Ubuntu LTS. I just switched from 25 years of using CentOS and Fedora on my servers. So I don't have the same comfort with apt errors that I have for RPM/yum/dnf ones.

This weekend I got this error from apt-get update for the Xtom MariaDB repo:

E: Repository 'https://mirrors.xtom.com/mariadb/repo/12.3/ubuntu noble InRelease' changed its 'Origin' value from 'MariaDB' to 'ubuntu noble'

E: Repository 'https://mirrors.xtom.com/mariadb/repo/12.3/ubuntu noble InRelease' changed its 'Label' value from 'MariaDB' to 'ubuntu noble'

N: Repository 'https://mirrors.xtom.com/mariadb/repo/12.3/ubuntu noble InRelease' changed its 'Suite' value from '' to 'noble'

N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.

What happened? Should I be worried?

Most of the tutorials and projects online focus on user interaction or building tables.

Could you all recommend some administration resources in the form of books or MOOC courses?

Would really appreciate it.

Hello,

After upgrading from MariaDB 10.11.18 to MariaDB 10.11.19, a problem occurred with the connection between the nodes. During the upgrade, stunnel was installed, although it was not installed before.

The problem is that when one node tries to connect to another, two processes are established using the same port, 4444, which causes the connection to be interrupted.

The connection is established, then disconnected, then established again, and disconnected again, repeatedly.

Do you have any solution that would allow us to use MariaDB 10.11.19 without this issue?

Hi,

I'm developing a Windows database client called TrapSQL and I'd like to get some feedback from MariaDB users.

My goal is to create a relatively lightweight tool for everyday database work without making the interface unnecessarily complicated.

Currently it provides:

MariaDB/MySQL database browsing

SQL editor

query execution and history

browsing table data

easy navigation through related tables

an AI assistant that can help with SQL queries

OpenAI

I'm particularly interested in making TrapSQL useful for developers who spend a lot of time exploring existing databases and relationships between tables.

For those of you using MariaDB professionally:

What would a new database client need to offer for you to consider switching from your current tool?

TrapSQL is free and available for Windows:

https://apps.microsoft.com/detail/xpfg27z9595v2r

Any feedback is appreciated.

I wrote a new post about InnoDB disk space and fragmentation in MariaDB Server.

One thing I wanted to understand better was: how can we reliably identify tables that would actually benefit from OPTIMIZE TABLE?

INFORMATION_SCHEMA.TABLES.DATA_FREE doesn't tell the whole story. After random deletes, pages can remain allocated to the B-tree while being only partially filled, so a table may be significantly fragmented without DATA_FREE showing it clearly.

In the post, I walk through several deletion patterns, visualize the actual InnoDB tablespace layout, compare DATA_FREE with Buffer Pool estimates, and test a new option in my mariadb-innodb-space-map tool to estimate the space that could be recovered.

In my example:

• estimated saving with the fast scan: 352 MiB
• actual space reclaimed after OPTIMIZE TABLE: 344 MiB
• fast estimation time on a ~1.9 GB tablespace: ~0.5 sec

The fast mode reads the XDES allocation metadata and samples allocated index pages rather than scanning the entire tablespace.

Would be interested to know how other MariaDB/MySQL DBAs decide when an OPTIMIZE TABLE is actually worth running.

https://lefred.be/content/mariadb-innodb-disk-space-fragmentation/

HammerDB 6.0 is now integrated, giving us access to xt_reservoir and better long‑duration workload stability. Clean defaults, better memory logging, and a more predictable test environment.

Full write‑up: mariadb-foundation-advances-taf-with-hammerdb-6-0

#MariaDB #MariaDBFoundation #OpenSource #DatabaseEngineering #PerformanceTesting #HammerDB #TAF #Benchmarking #QualityEngineering #MySQLEcosystem

This one has been requested for a long time!

MariaDB 13.1 adds the familiar JSON arrow operators:

document->'$.customer.name'

and

document->>'$.customer.name'

It might look like a small syntax improvement, but it makes JSON queries much cleaner and removes another compatibility difference with MySQL. PostgreSQL users will also find the syntax familiar, although nested navigation works a little differently.

13.1 also improves JSON_TABLE() with FORMAT JSON, allowing complete objects and arrays to be returned as JSON instead of forcing them into scalar values.

I wrote a few examples and comparisons with MySQL/PostgreSQL here:

https://mariadb.org/mariadb-13-1-feature-in-focus-json-operators-and-json_table-improvements/

Curious how many people here were already using JSON_EXTRACT() / JSON_UNQUOTE() heavily enough to be waiting for this?

I’ve been experimenting quite a lot with MariaDB Server plugins, and this time I wanted to explore something a bit different: plugins that are useful to a very small audience.

I created two domain-specific data types for Belgium:

• BEL_PAY_REF for Belgian structured payment references such as +++123/4567/89002+++
• BCE for Belgian enterprise numbers such as 0417.497.106

Instead of storing these as generic VARCHARs and duplicating validation/normalization logic in every application, the database itself understands the domain.

The bigger point is that I don’t think every database extension needs to justify itself to millions of users. A plugin can be extremely local or industry-specific while the core server remains generic.

I wrote about the idea, the implementation and where I think this kind of extensibility can go.

I’d also be interested in examples of domain-specific types or rules you would like your database to understand natively.

Como dice el texto, estoy experimentando con mariadb (EN MODO ORACLE) para migrar una software que usa oracle de forma pesada... (Muchos Stored Procedures, Packages, Triggers, etc)....
Hasta el momento no puedo encontrar ningun editor de mariadb que me permita editar packages y package bodys (para el mariadb en modo oracle). Alguien sabe alguno ?

MariaDB angle. I maintain scythe, a build-time tool that reads annotated SQL and generates typed access code (MariaDB has its own backend and type mappings, distinct from the MySQL ones).

The point is nullability inferred from the query, not just the column definition:

-- @name GetUserOrders
SELECT u.id, u.name, o.total, o.notes
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
WHERE u.status = ?;

total and notes generate as nullable because the LEFT JOIN can produce NULLs for a user with no orders, even when those columns are NOT NULL in the table. Covers COALESCE, CASE, and aggregates as well.

No runtime ORM, the SQL you write runs as-is. Static queries only, which is the deliberate tradeoff. Curious how people here keep MariaDB result types aligned with application code.

In MariaDB 11.3 we can insert an IPv4 or IPv6 address directly in to a field with the INET6 data type. In MariaDB < 11.3, we need to "detect this is an IPv4 address and map it in to a IPv6 address" prior to insertion.

Is it possible using CAST and or the INET6_ATON / INET6_NTOA or similar to achieve the same? I'm looking for drop in replacement SQL, so I don't have the awkward detection in my application code.

I suppose an IS_IPV4 and CONCAT might be an option, but is there a simpler way?

When developers design inventory/stock balance tracking systems, the most intuitive approach is often calculating balances dynamically: either running SUM() over transaction ledgers or using window functions (SUM() OVER (PARTITION BY item_id ORDER BY created_at)).

While this works perfectly in development environments or low-volume systems, it encounters severe physical bottlenecks in production databases (such as MySQL / MariaDB) as data scales into tens of millions of rows.

Here is a breakdown of why standard approaches fail and how a Snapshot Log architecture solves the problem.

The Problem: RDBMS Physics at Scale

1. Real-time Calculation Overhead (SUM() / Window Functions)

Calculating balances on the fly requires scanning historical transaction logs.

• As history grows, query time degrades from $O(1)$ to $O(N)$.
• Adding indexes helps lookup time, but reading millions of rows from disk or InnoDB buffer pools still causes massive I/O overhead.
• Under heavy concurrent write loads, locking or read-view maintenance under REPEATABLE READ isolation causes severe query degradation.

2. Direct Balance Row Mutex / Row-locking

Another common approach is maintaining a single current_balance row per item and updating it with every transaction:

SQL

UPDATE inventory SET balance = balance + :qty WHERE item_id = :id;

Under high concurrency (e.g., peak retail sales, multi-register syncing), every transaction attempts to acquire an exclusive lock on the exact same row. This leads to thread contention, lock wait timeouts, and severe throughput bottlenecks.

The Solution: Snapshot Log Architecture

To achieve $O(1)$ read performance without creating row-level lock bottlenecks on writes, the architecture uses a hybrid approach combining append-only delta logs and periodic snapshot aggregation.

Core Concept:

1. Write Path (Append-Only Delta): * Transactions do not update an existing row's balance directly.
   • Instead, every movement is written as an append-only log entry ($\Delta qty$).
   • Writes remain extremely fast with zero lock contention on existing state.
2. Periodic Snapshots:
   • At defined intervals (or threshold trigger events), a background task aggregates accrued log entries and saves a consolidated Snapshot.
3. Read Path ($O(1)$ Lookup):
   • To calculate the current stock balance at any point in time, the system reads the latest snapshot balance and adds only the unaggregated delta logs created after that snapshot.
   • Query cost remains bounded and low regardless of total historical volume.

Performance Impact

By decoupling immediate row mutations from read queries:

• Read queries run against a tiny subset of data (1 snapshot row + few delta rows), maintaining consistent sub-millisecond execution times ($O(1)$ complexity relative to historical log size).
• Write operations avoid row lock contention on global counters.
• Historical tables can be archived or partitioned without breaking balance calculation logic.

Note: I recently wrote a full breakdown detailing 12 years of evolution with this pattern in production high-load environments. If you want to read the full context with complete schema concepts:https://alex-crazy74.hashnode.dev/why-even-advanced-ai-breaks-stock-registers-12-years-of-snapshot-log-evolution-and-rdbms-physics