MariaDB 11.8 arrives with significant improvements in performance, optimization, and compatibility, as well as new SQL functionalities and internal changes worth knowing.

The new version incorporates significant improvements in performance, optimization, compatibility, and new SQL functionalities. And although for most modern websites it won’t pose any problem, there are some changes worth reviewing if you work with custom developments or old applications.

Especially if your project heavily depends on advanced SQL queries, specific collations, stored procedures, or legacy logic.

The good news is that, in most cases, you won’t have to touch anything.

The less good news: if you have very old or manually optimized code, it is worth doing some checks.

Who might be affected by this MariaDB update?

If you use an updated WordPress along with common plugins and themes, you can be quite calm.

Normally, everything will continue to work exactly the same after the update.

The cases where we do recommend reviewing the behavior are:

• old or unmaintained applications
• custom-made developments
• direct integrations with MariaDB
• complex SQL queries
• old charset or collation configurations
• triggers and stored procedures
• systems with replication or external integrations

In other words: the more customized the project, the more advisable it is to validate some points.

The most important change: utf8mb4 becomes the default charset ⚠️

One of the most relevant changes in MariaDB 11 is that the default charset is no longer latin1 and becomes utf8mb4.

And yes: this matters more than it seems.

Why might it affect?

Because many old applications never explicitly defined the charset of their tables or columns.

They simply assumed the server’s default value.

With MariaDB 11 that changes.

What might start behaving differently?

Mainly:

• text comparisons
• searches
• sortings (ORDER BY)
• groupings (GROUP BY)
• string equality
• handling of special characters or emojis

In some projects, this will have no impact.

In others, especially old or multilingual applications, it can cause visible differences.

So, what should be reviewed?

Especially:

• tables created years ago
• columns without explicit charset
• applications mixing different collations
• logic dependent on the exact order of results

If you want to maintain specific behavior, it is advisable to explicitly define charset and collation in tables and columns.

The default Unicode collation also changes

MariaDB 11.8 now uses uca1400_ai_ci as the default Unicode collation.

Translated to the real world: some text comparisons and sortings may behave slightly differently.

Where is it usually noticeable?

Especially in:

• multilingual applications
• internal searches
• textual filters
• systems with complex sortings
• comparisons between Unicode characters

For example, strings that were previously considered «equal» might no longer be, or vice versa.

It’s not dramatic, but it is advisable to review if your application heavily depends on searches or textual comparisons.

Queries may change behavior (even if they work better)

MariaDB 11 incorporates many improvements in the SQL optimizer.

And this, in general, is good news.

Many queries are executed more efficiently thanks to new optimization criteria and smarter indexes.

The problem is that, in some cases, the execution plan may change compared to previous versions.

What type of queries should be reviewed?

Especially:

• UPDATE and DELETE with subqueries
• queries with:
  • DATE()
  • YEAR()
  • SUBSTR()
  • UCASE()
• partitioned tables
• virtual columns
• manually optimized queries

MariaDB can now use indexes in situations where it couldn’t before.

Normally this improves performance.

But if your application depended on very specific optimizer behavior, it is advisable to validate it.

The most sensible recommendation

Review critical queries using:

EXPLAIN

especially if the project has a heavy load or advanced SQL logic.

Triggers and stored procedures are now stricter

Another important point: MariaDB 11 tightens some internal validations related to routines, triggers, and stored functions.

What does this mean?

That certain old procedures, dynamic SQL, or non-standard syntax might start causing problems when recreated or validated.

Additionally, UPDATE triggers can now only execute when certain columns change.

This opens new possibilities, but it can also change behaviors in some legacy systems.

Should you be concerned?

Only if you use:

• complex stored procedures
• custom triggers
• dynamic SQL
• old logic maintained for years

In modern applications or common CMS, this rarely poses a problem.

Some old variables disappear or become deprecated

As happens in almost any major version jump, MariaDB 11 removes some legacy compatibility.

Some variables already removed

• old_alter_table
• wsrep_load_data_splitting
• old OQGraph variables

Deprecated variables

• tx_isolation
• spider_casual_read

What should you review

Especially:

• automation scripts
• custom configurations
• internal tools
• old deployments

Many times the problem is not in the web application, but in forgotten scripts that still use old syntax.

MariaDB 11 also brings interesting improvements

Not everything is about compatibilities and reviews 😄

The new version also adds quite powerful functionalities.

New UUID functions

Now you can use:

UUID_v4()
UUID_v7()

directly from MariaDB.

Improvements in JSON

MariaDB continues to significantly improve JSON support with functions like:

• JSON_SCHEMA_VALID()
• JSON_ARRAY_INTERSECT()
• JSON_OBJECT_FILTER_KEYS()

very useful in modern applications and APIs.

Vector functions and semantic search

Yes: MariaDB is also starting to enter the AI world.

The new version incorporates:

• vector types
• vector indexes
• similarity functions

oriented towards semantic searches and modern applications related to embeddings or AI.

So… should you do something?

For most projects: probably not.

If you use modern applications, common CMS, or updated software, the migration is usually completely transparent.

Where we do recommend reviewing is in projects:

• old
• highly customized
• with advanced SQL
• with legacy logic
• with direct integrations against MariaDB

In those cases, it is worth validating:

• collations
• critical queries
• triggers
• stored procedures
• old configurations

If you want to be on the safe side, a good practice is to test the application in staging environments before the final update, especially in critical projects or with a lot of custom development.