MariaDB 12.3 vs 11.8 and 10.11: An LTS Version Guide

Choosing among MariaDB LTS versions is a lifecycle decision, not a contest to install the largest version number. In August 2026, MariaDB Foundation information identifies 12.3 as the newest LTS, while 11.8, 11.4, and 10.11 remain highly relevant across existing deployments, Linux distributions, and application support matrices. Documentation pages can lag release announcements, distribution repositories intentionally ship older maintained branches, and a connector that can establish a session is not proof that every query and operational tool is compatible.

This guide explains how to choose a MariaDB release for a new system or upgrade. It focuses on evidence that matters in production: who supplies the package, how long that supplier maintains it, whether the application certifies it, what configuration and optimizer behavior may change, whether backups can be restored, and how rollback would actually work after system tables are upgraded.

The goal is not to nominate one branch for every workload. It is to produce a defensible version decision and a tested transition plan.

Why MariaDB version advice becomes outdated quickly

MariaDB publishes multiple release lines. Linux distributions package selected lines on their own schedules. MariaDB Foundation and MariaDB Corporation documentation can describe Community and Enterprise products with different maintenance terms. Search results may also cache a page that was correct months ago but predates a new LTS announcement.

Use a source hierarchy:

1. Current MariaDB Foundation release policy and announcements for Community release status.
2. Release notes for the exact target series and patch.
3. The official upgrade guide for the exact source-to-target path.
4. The package repository visible to the target operating system.
5. The application vendor's supported database matrix.
6. Connector, proxy, backup, monitoring, and orchestration compatibility.

Do not infer support from a generic article that says “latest MariaDB.” Capture the date and URL of every decision source in the change record.

Current LTS landscape in 2026

The following comparison is deliberately qualitative because support dates and current patch releases change. Verify them again when implementing the change.

MariaDB Foundation announced that 10.6 reached end of life on July 6, 2026. A final binary release does not restore an ongoing security-maintenance lifecycle. Remaining on 10.6 requires a documented external support arrangement or a time-bound migration plan.

New LTS does not mean “install immediately everywhere.” It means the branch is intended for longer maintenance. A production adoption date should follow successful tests, available packages, tool support, and recovery rehearsal.

Distribution package versus upstream package

Ubuntu 24.04 ships a MariaDB package based on the 10.11 family. Ubuntu, not the upstream repository, determines the package patching and integration lifecycle. The version string may include Ubuntu revisions that do not correspond directly to the newest upstream patch number.

Inspect the actual source:

apt-cache policy mariadb-server mariadb-client mariadb-backup
apt-cache madison mariadb-server
grep -R --line-number -E 'mariadb|mysql' 
  /etc/apt/sources.list /etc/apt/sources.list.d 2>/dev/null
dpkg-query -W -f='${Package}t${Version}n' 
  mariadb-server mariadb-client 2>/dev/null

An upstream repository provides more branch choice but also makes branch selection your responsibility. MariaDB's repository setup documentation warns that the default can point to a rolling repository. Production automation should specify an approved series through the documented --mariadb-server-version option and verify the candidate afterward.

curl -fsSLo /tmp/mariadb_repo_setup 
  https://downloads.mariadb.com/MariaDB/mariadb_repo_setup
less /tmp/mariadb_repo_setup
sudo bash /tmp/mariadb_repo_setup --help

Do not execute a downloaded setup script without review. Do not assume an example version identifier is still accepted; consult its current help and official documentation. After configuration:

sudo apt update
apt-cache policy mariadb-server mariadb-client mariadb-backup

Stop if the candidate is not the intended series or repository. A package hold can prevent surprise upgrades, but forgotten holds also block security fixes. Prefer controlled repository configuration, maintenance automation, and alerting on available patch releases.

Select a version using workload evidence

Create a written decision matrix for each service. At minimum, answer these questions.

Does the application vendor support the exact series?

“MySQL-compatible” is not a support statement. Check the application's MariaDB version matrix, ORM, migration framework, JDBC/ODBC/Python/Node connector, backup agent, and observability exporter.

Inventory application dependencies:

dpkg -l | grep -E 'mariadb|mysql|odbc' || true
find /srv /opt -maxdepth 4 -type f 
  ( -name 'composer.lock' -o -name 'package-lock.json' 
     -o -name 'requirements.txt' -o -name 'pom.xml' ) 
  -print 2>/dev/null

Do not upload dependency files to public scanners if they expose private package names or repository URLs. Review them in the organization's approved tooling.

Which server features are used?

Inventory storage engines, collations, plugins, SQL modes, replication, Galera, temporal tables, partitioning, event scheduler, encryption, and authentication plugins.

SELECT VERSION(), @@version_comment;
SHOW ENGINES;
SHOW PLUGINS;
SELECT @@global.sql_mode, @@global.time_zone;
SHOW VARIABLES LIKE 'character_set_server';
SHOW VARIABLES LIKE 'collation_server';
SHOW VARIABLES LIKE 'log_bin';

For an estate, collect this through an authenticated, read-only process and protect the output. Plugin names and configuration details can reveal security-relevant architecture.

Is the workload sensitive to optimizer changes?

Major releases can choose different execution plans even when SQL remains valid. Capture representative queries, latency percentiles, row counts, and plans before migration. A faster average does not compensate for one critical query becoming unbounded.

SHOW GLOBAL STATUS LIKE 'Slow_queries';
SHOW VARIABLES LIKE 'slow_query_log';
SHOW VARIABLES LIKE 'long_query_time';

Use the slow query log in a controlled window with suitable retention and permissions. Logs may contain query literals and personal data.

What recovery target must the upgrade preserve?

Define RPO, RTO, acceptable maintenance, and rollback cutoff. If the only backup takes six hours to restore, a two-hour rollback promise is fictional.

New deployment: how to choose

For a new service, choose the newest LTS that all critical components support and the team can operate. “Operate” includes backup, restore, monitoring, failover, security patching, and on-call diagnosis.

Choose 12.3 LTS when:

• The branch is GA and available from an approved package source.
• The application and connectors certify it.
• Required plugins and backup tools support it.
• The team has validated configuration defaults and failure recovery.
• There is no dependency on an older distribution package contract.

Choose 11.8 or 11.4 when:

• Vendor support or field maturity is more important than the newest feature set.
• The planned platform standard already uses that line.
• A tested upgrade path from an existing fleet exists.
• A newer LTS lacks support in a required tool.

Choose Ubuntu's 10.11 package when:

• Distribution support and package integration satisfy the service lifecycle.
• The application has a conservative certification matrix.
• The next migration is documented rather than ignored.
• Upstream-only features are not required.

Never select an end-of-life branch for a new system merely because a team knows it. Familiarity is not a substitute for security maintenance.

Existing deployment: stay or upgrade?

Staying is reasonable when the branch remains supported by the responsible supplier, security fixes are delivered, the application is certified, and the operational risk of change exceeds the benefit at this moment. Staying becomes neglect when there is no documented review date or migration rehearsal.

Collect baseline evidence:

sudo mariadb -e "SELECT VERSION(), @@version_comment, @@hostname;"
apt-cache policy mariadb-server mariadb-client
sudo mariadb -e "SHOW GLOBAL STATUS WHERE Variable_name IN (
  'Uptime','Threads_connected','Threads_running','Questions',
  'Slow_queries','Aborted_connects'
);"
sudo du -sh /var/lib/mysql
df -hT /var/lib/mysql

Record peak, not only current, resource use. Capture backup duration, restore duration, replication lag, and the longest maintenance operation. These values determine whether an in-place or staged transition is realistic.

Build an upgrade path, not a version jump

MariaDB publishes specific Community upgrade-path documentation such as 10.11 to 11.4 and 11.4 to 11.8. Use the exact guides that connect the source and target. When there is no direct documented path for a new release, wait for official guidance or stage through supported steps.

An upgrade plan should include:

1. Source and target exact package versions.
2. Release notes for every crossed series.
3. Removed, renamed, deprecated, or changed-default options.
4. Storage-engine and plugin compatibility.
5. Backup and proven restore instructions.
6. Clean shutdown requirements.
7. Repository change and package commands.
8. mariadb-upgrade execution and validation.
9. Application smoke, correctness, and performance tests.
10. Replication or Galera-specific procedure.
11. Cutover and rollback decision points.

Do not use a generic standalone-server procedure for Galera. Cluster upgrades have ordering, state transfer, quorum, and compatibility requirements that need the Galera guide.

Create a realistic rehearsal environment

Restore a recent backup into an isolated host with production-like CPU, memory, storage, filesystem, configuration, and data volume. Sanitized sample data may be appropriate for developers, but it often fails to reproduce optimizer and migration behavior caused by real cardinality.

Capture configuration without printing secrets:

sudo find /etc/mysql -type f -maxdepth 4 -print
my_print_defaults mariadb mariadbd server mysqld
sudo mariadb -NBe "SHOW VARIABLES" > /secure/path/source-variables.tsv

The variables file can contain paths, topology details, and security settings. Store it with restricted access.

Before the rehearsal:

sudo mariadb -e "SHOW WARNINGS;"
sudo mariadb-check --all-databases --check-upgrade
sudo mariadb -e "SHOW FULL PROCESSLIST;"

mariadb-check can be expensive on large estates depending on options and table types. Test its duration and I/O impact before running it during a production window.

Back up for an upgrade you can reverse

Take a physical or logical backup supported by the source version. A physical backup normally provides faster recovery for large datasets; a logical dump is portable and useful for validation but can take much longer.

Example logical baseline:

sudo mariadb-dump --all-databases 
  --single-transaction --routines --events --triggers 
  | gzip > /secure/backup/preupgrade-$(date +%F-%H%M%S).sql.gz
gzip -t /secure/backup/preupgrade-*.sql.gz

This does not prove restore performance. Restore the artifact into the rehearsal system and verify users, grants, routines, events, triggers, schemas, row counts, checksums where appropriate, and application behavior.

For physical backups, use the mariadb-backup version and procedure compatible with the source. Prepare and restore are distinct operations. Never overwrite the production data directory as a “test.”

Check configuration changes before package replacement

List custom settings and compare them with each target series' removed and changed options:

sudo grep -R --line-number -E '^[[:space:]]*[a-zA-Z_]' 
  /etc/mysql 2>/dev/null
my_print_defaults mariadb mariadbd server mysqld

Remove obsolete options in the rehearsal copy first. A server that fails at the first start because of one unknown variable lengthens an outage; a server that silently accepts a deprecated no-op option can be worse because operators believe a control is active.

Validate startup and inspect warnings:

sudo systemctl start mariadb
systemctl status mariadb --no-pager
sudo journalctl -u mariadb --since "10 minutes ago" --no-pager

Do not suppress unknown-option errors to force startup. Determine the target equivalent or remove the setting with a documented reason.

Run mariadb-upgrade at the correct point

For a major upgrade, start the new server successfully, then run:

sudo mariadb-upgrade

The utility updates system tables and checks table compatibility. Back up before running it. A schema and system-table upgrade changes the rollback problem: reinstalling old binaries over a data directory already opened and modified by a newer server is not a reliable rollback method.

Capture results:

sudo mariadb-upgrade --verbose
sudo mariadb -e "SELECT VERSION(), @@version_comment;"
sudo mariadb-check --all-databases
sudo journalctl -u mariadb --since "30 minutes ago" --no-pager

Do not use --force merely to make output look successful. Understand why the utility thinks the upgrade already ran and whether the documented path requires a forced check.

Test application compatibility and performance

Build tests around behavior, not a successful TCP connection:

• Login and authorization paths.
• Reads and writes for critical entities.
• Transactions, rollback, and deadlock retry.
• Migrations and schema introspection.
• Unicode, sorting, and case sensitivity.
• Date, time, and timezone behavior.
• Prepared statements and connector pooling.
• Batch jobs, reports, and large queries.
• Backup, restore, replication, and monitoring.

Compare query plans for critical SQL:

EXPLAIN FORMAT=JSON
SELECT ...;

Use production-representative parameters and data distribution. Do not publish raw plans containing sensitive literals or table names without review.

Measure p50, p95, and p99 latency as well as throughput and resource use. A new optimizer may improve many queries and regress a few. Release acceptance should include thresholds and owners for regressions.

Prefer staged rollout for critical systems

An in-place upgrade is simple but concentrates risk and usually makes rollback dependent on restoring a backup. A staged approach can provision a new target-version server, copy or replicate data through a supported mechanism, validate it, and switch clients at a controlled point.

Benefits include:

• The source remains available during most testing.
• Target configuration is built cleanly.
• Restore and synchronization behavior are exercised.
• Application testing can occur before cutover.

Costs include:

• Additional infrastructure.
• More complex data synchronization.
• Careful handling of writes and cutover consistency.
• Replication compatibility and failback constraints.

Do not assume a newer replica can always be promoted and then replicate back to an older primary. Validate direction, feature use, DDL, GTID behavior, and rollback design.

Common version-selection mistakes

Treating a distribution patch number as unmaintained

Ubuntu can backport fixes without matching the latest upstream patch string. Determine the responsible supplier and inspect its security notices rather than comparing only VERSION().

Following an outdated “latest LTS” page

Documentation is updated asynchronously. Cross-check the current Foundation announcement, release notes, downloads, and repository availability. Record the research date.

Configuring the upstream rolling repository accidentally

The repository setup default may track a rolling series. Always inspect the generated source and apt-cache policy before installation.

Assuming protocol compatibility equals application compatibility

An older connector may connect but mishandle authentication, metadata, collations, server capabilities, or failover. Run real application tests.

Treating downgrade as rollback

MariaDB is not designed for arbitrary downgrades. Once new binaries and mariadb-upgrade change the data and system tables, recovery should normally use the tested backup or staged source system.

Skipping restore rehearsal

A backup job exit code does not prove the artifact is complete, decryptable, transferable, or restorable within RTO.

Version-decision checklist

Approve a MariaDB series only when:

• The Community, distribution, or commercial support owner is explicit.
• The maintenance horizon covers the service plan.
• The exact package source and patch process are documented.
• The application and connectors support the series.
• Required storage engines and plugins are available.
• Configuration changes are inventoried.
• Representative queries meet correctness and latency thresholds.
• Backup and restore are tested at production scale.
• Replication, Galera, proxy, and monitoring components are compatible.
• Upgrade and rollback runbooks have been rehearsed.
• Operators can diagnose startup, authentication, storage, and query failures.
• A review date exists for the next lifecycle decision.

FAQ

Is MariaDB 12.3 the latest LTS in 2026?

MariaDB Foundation announced 12.3 as its newest LTS in 2026. Verify the current release status, GA patch, repository availability, and support policy at implementation time because documentation pages may lag announcements.

Is MariaDB 10.11 still suitable for production?

Yes, when it remains maintained by the responsible package supplier and meets the application's lifecycle. Ubuntu 24.04 uses the 10.11 family. Document the future transition rather than treating it as permanent.

Should a new deployment always use MariaDB 12.3?

No. Use the newest LTS supported by the application, connectors, tools, and operations team. A slightly older maintained LTS can be lower risk until the ecosystem certifies the newest branch.

Is MariaDB 10.6 still supported?

MariaDB Foundation stated that Community Server 10.6 reached end of life on July 6, 2026. Organizations still using it need a supported-provider agreement or urgent migration plan.

Can Ubuntu's MariaDB package be upgraded by adding the upstream repository?

It can be a valid migration path, but it is not a routine patch update. Review package differences, repository priorities, exact upgrade guides, configuration, backups, and restore before changing sources.

Can I upgrade directly from 10.11 to 11.8 or 12.3?

Follow the currently documented Community upgrade paths. If an exact direct path is not documented, do not invent one; stage through supported branches or wait for official guidance.

Does mariadb-upgrade run before or after starting the new server?

Run it after the new server starts successfully. Back up first, because it updates system tables and checks table compatibility.

What is the safest rollback from a major upgrade?

Restore the tested pre-upgrade backup or switch back to a preserved staged source. Reinstalling old binaries over a data directory modified by the new server is not a dependable rollback.

Conclusion

Selecting among MariaDB LTS versions requires more than reading a release number. MariaDB 12.3 may be the newest LTS, but 11.8, 11.4, and 10.11 remain valid choices when their support source, application certification, and operational evidence align with the service lifecycle. The wrong choice is an unsupported branch or an untested upgrade chosen by habit.

For new systems, prefer the newest LTS that the complete ecosystem supports. For existing systems, use a documented review date, representative workload tests, official upgrade paths, a restored backup, and explicit rollback gates. Treat package source, configuration, optimizer behavior, tools, and recovery as part of the version decision. That is how an LTS label becomes a reliable production platform rather than a false sense of safety.

Suggested Internal Links

• Install MariaDB on Ubuntu 24.04: Production Setup Guide — /install-mariadb-ubuntu-24-04/
• Upgrade MariaDB Safely Across Major Versions — /upgrade-mariadb-major-version/
• Back Up MariaDB with mariadb-dump and Safe Restore Tests — /mariadb-dump-backup-restore/
• Create Physical Backups with MariaDB Backup — /mariadb-backup-physical/
• Build a MariaDB Production Maintenance Runbook — /mariadb-maintenance-runbook/

Suggested External Sources

• MariaDB Foundation release policy — https://mariadb.org/about/
• MariaDB Community Server release notes — https://mariadb.com/docs/release-notes/community-server
• MariaDB latest releases — https://mariadb.com/docs/release-notes/latest-releases
• MariaDB Community upgrade paths — https://mariadb.com/docs/server/server-management/install-and-upgrade-mariadb/upgrading/mariadb-community-server-upgrade-paths
• Upgrading between major MariaDB versions — https://mariadb.com/docs/server/server-management/install-and-upgrade-mariadb/upgrading/platform-specific-upgrade-guides/upgrading-on-linux/upgrading-between-major-mariadb-versions
• MariaDB repository setup and usage — https://mariadb.com/docs/server/server-management/install-and-upgrade-mariadb/installing-mariadb/binary-packages/mariadb-package-repository-setup-and-usage
• mariadb-upgrade reference — https://mariadb.com/docs/server/clients-and-utilities/deployment-tools/mariadb-upgrade
• MariaDB 10.6 end-of-life announcement — https://mariadb.org/mariadb-server-10-6-reaches-end-of-life-on-july-6th/