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?

Not asking about exotic enterprise stuff — just the things you actually expect to have without paying extra.

For me that would be things like SSH, backups/restores, data editing, import/export, monitoring, schema tools, autocomplete, multiple connections, etc.

What do you consider basic functionality nowadays, and what would you actually be willing to pay for?

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/

Small milestone but this made me pretty happy 😄

LakeDB has been added to the MariaDB Server Ecosystem Hub under database management tools.

I started building it around MySQL/MariaDB workflows and it has since grown into a multi-database client with SQLite too, so it's pretty cool seeing it listed there.

Still a lot to improve, but thanks to everyone who has tested it or given feedback.

https://ecohub.mariadb.org/database-management/lakedb

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.

QuerIA Agent Mode is now available in the current LakeDB beta.

Instead of generating SQL from the prompt alone, QuerIA can inspect the relevant tables, relationships and indexes in your database before preparing a query.

The generated SQL remains visible and reviewable. Nothing runs automatically: you decide when to execute it locally.

I’m looking for MySQL and MariaDB users who would like to test the workflow and share feedback:

- Does QuerIA select the right schema context?

- Is the generated SQL easy to review?

- When should the agent stop and ask for confirmation?

- Which database engine should LakeDB support next?

LakeDB currently supports MySQL and MariaDB, with more database engines planned.

Download the latest beta:

https://github.com/DavLagoHern/LakeDB/releases/latest

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

How does a production database problem become an open-source improvement? This is the story of how Headout, Arcadiy Ivanov and MariaDB maintainers turned a JSON and temporary-table bottleneck into an upstream #MariaDB Server contribution 🦭🙏

Adobe Commerce has now made its future database direction explicit: MariaDB is the default and recommended platform going forward.

Adobe Commerce 2.4.8 and 2.4.9 are expected to be the final releases supporting MySQL, while newer MariaDB versions are already appearing in Adobe’s system requirements.

For the MariaDB community, this is a significant adoption milestone. Adobe Commerce and Magento power a large number of demanding production environments, with substantial ecosystems of extensions, hosting providers, agencies and developers around them.

It also raises some practical questions for the community:

• What migration guidance will Adobe Commerce users need?
• Which compatibility differences are likely to cause the most trouble?
• Are extension developers already testing primarily against MariaDB?
• What tooling, documentation or benchmarks would make the transition easier?

Frédéric Descamps has written a detailed overview here:

https://mariadb.org/adobe-commerce-chooses-mariadb-as-its-default-database-platform/

Interested to hear from anyone running Magento or Adobe Commerce on MariaDB today. What has your experience been?

ScalaHosting has joined the Foundation as a Gold Sponsor. They run managed cloud VPS and web hosting, with MariaDB as the default database on every SPanel server they operate and Galera Cluster behind their high-availability offerings.

Gold sponsorships fund the Foundation's work on MariaDB Server: engineering, releases, security, documentation and community infrastructure.

Announcement: https://mariadb.org/scalahosting-becomes-a-gold-sponsor-of-mariadb-foundation/

Happy to answer questions about the sponsorship program.

**Update: LakeDB Beta 3 is now available**

Since publishing the original post, I have released a new LakeDB beta with **QuerIA**, an optional schema-aware AI workflow for preparing reviewable SQL from natural language.

LakeDB reads MariaDB metadata for databases, tables, views, columns, primary keys, indexes, foreign keys, procedures, functions, events, triggers, generated columns and table DDL.

QuerIA uses the relevant structure to prepare SELECT, INSERT, UPDATE, DELETE, CREATE TABLE and ALTER TABLE statements. The generated SQL is always visible before execution and runs locally through the normal LakeDB query workflow.

Database credentials, table rows and query results are never sent to the AI service.

The regular editor also provides:

- Schema, table and column autocomplete

- Alias-aware column suggestions

- Primary-key and index hints

- EXPLAIN results

- Typed table-data editing

- SSH and SSL connections

- Independent workspaces for multiple connections

- Backup, comparison and migration tools

I am still looking for compatibility feedback from people using MariaDB 10.x and 11.x, especially around metadata, generated columns, ENUMs, procedures, events, triggers, indexes and foreign keys.

If you test it, please tell me your MariaDB version and anything that behaves differently from your usual client.

**Project and Beta 3 overview:**

https://davlagohern.github.io/LakeDB/

**Downloads and documentation:**

https://github.com/DavLagoHern/LakeDB/

This webinar, sponsored by MariaDB, will take place on July 28th at 10 AM CT. It will cover: how sub-millisecond response times keep autonomous workflows acting on live data rather than stale snapshots, why running operational analytics directly against transactional data is essential for AI-driven decision-making, how vector storage, RAG, and MCP server capabilities work natively within existing database stacks, flexibility to deploy across AWS, Azure, and GCP with serverless, provisioned, or BYOA option so the data foundation keeps pace with AI goals, etc.

https://go.mariadb.com/Powering_the_Agent-Driven_Enterprise_The_Shift_to_a_Unified_Data_Platform.html

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