LTS vs Innovation Releases, Support Horizons, Upgrade Cadence, and Version Selection

Learning outcomes

ServiceHub now has a running MariaDB server, and the infrastructure team asks which release should become the production standard. Someone sorts version numbers and picks the numerically highest build. Another insists that the curriculum’s “11.8 LTS” wording must remain the production baseline forever. Neither approach accounts for MariaDB’s current release model, release maturity, support horizon, operating-system packages, connectors, plugins, backup tooling, or topology compatibility.

This lesson teaches version selection as a lifecycle decision. As of the course review on 20 August 2026, MariaDB Foundation lists 12.3.2 as the stable release in the latest long-term-support (LTS) line, while 13.0.1 is a release candidate in the rolling line and 13.1 is preview. The published Big Data Academy MariaDB curriculum still records 11.8 LTS as its coverage baseline, so we preserve 11.8 for comparison while using 12.3.2 for current Chapter 01 Community labs.

1. Release maturity is separate from version number

MariaDB publishes releases with different maturity states. A preview exists for early evaluation; a release candidate (RC) is closer to release but is still not the production baseline for this course; a stable/GA release is the normal candidate for production evaluation. The Foundation also distinguishes long-term releases from rolling releases. You must therefore read the status next to the version, not just the version itself.

This table is intentionally dated. MariaDB releases patch updates and new series regularly, and security/corrective releases can appear outside a simple quarterly rhythm. A future learner must replace this snapshot with current official data rather than treating it as evergreen truth.

2. Understand the current numbering and lifecycle policy

MariaDB Foundation currently describes the three-part version number as a.b.c: the first component identifies the major version family, the second tracks functionality/release-series progression, and the third is the patch/maturity component. Starting with MariaDB 12, the Foundation expects the first number to increase yearly, while rolling releases progress through feature series and the largest b in a major family becomes its LTS branch.

Support horizons are not monotonic by version number. MariaDB 11.4 has a longer Community maintenance horizon than 11.8 under the published policy, while 11.8 belongs to a newer yearly-LTS cadence with a different window. That is a strong warning against rules such as “newer minor always stays supported longer.” Query the official lifecycle page for the series you operate.

SELECT VERSION() AS version,       @@version_comment AS version_comment,       @@version_source_revision AS source_revision,       @@version_compile_os AS compile_os,       @@version_compile_machine AS compile_machine;

The server can report its version and build metadata, but it cannot tell you future lifecycle dates. Lifecycle is external policy and must be read from current official sources.

3. Read support horizons as dated policy, not as a property of SQL syntax

Support lifecycle is an operational policy outside the SQL engine. At this review date, the MariaDB Foundation lifecycle table gives Community maintenance through June 2029 for 12.3, June 2028 for 11.8, May 2029 for 11.4, and February 2028 for 10.11; 10.6 reached Community end of life in July 2026. Those dates are useful planning evidence today, but they are deliberately not hard-coded as an eternal course rule. A vendor, Linux distribution, cloud service, or enterprise subscription can also have a support window that differs from the Foundation Community window.

The practical consequence is that “supported MariaDB” needs a qualifier. Ask: supported by whom, for which exact series, on which operating system/package channel, until what date, and for which components? A server can still start after Community EOL, but lack of maintained fixes changes its security and reliability posture. Conversely, a supported series does not guarantee that every optional plugin, connector, or Galera topology you depend on has the same horizon.

4. Patch updates and series upgrades are different changes

A patch release within a stable series—such as moving from one 12.3.x build to a later 12.3.x build—is primarily a maintenance/security/bug-fix operation. A release-series upgrade can introduce new features, changed defaults, removed behavior, optimizer changes, system-table changes, plugin compatibility changes, and operational prerequisites. Both require release-note review, but the blast radius is different.

The 12.3 LTS announcement demonstrates why defaults matter: MariaDB Foundation called out a change to the default of innodb_snapshot_isolation. Even if your application SQL is unchanged, a default change can alter transaction behavior. The correct response is not to fear upgrades; it is to inventory explicit/implicit dependencies, stage the target, and prove behavior under tests.

5. Version selection is a dependency graph

A database version is only useful if the surrounding stack can operate with it. The operating system or container base must have a supported package; the application connector must negotiate correctly; backup tooling must understand the server; optional plugins/storage engines must exist for that series; Galera provider compatibility must be verified for clustered nodes; replication peers must have a documented upgrade path; and your application must pass semantic and performance tests.

6. Deliberately wrong: “13.1 is the largest number, therefore it is the safest production choice”

This approach mistakes chronology for maturity. At review time 13.1 is a preview line, while 13.0.1 is RC and 12.3.2 is the latest stable LTS. A preview can be valuable for compatibility testing and future planning, but it is intentionally not the baseline for a production-oriented beginner lab.

The opposite mistake is freezing on 11.8 forever because an academy page once named it. MariaDB 11.8 remains a valid supported LTS line at this review date, but the academy’s job is to teach a process that survives changing releases. The repair is a selection gate: maturity → support horizon → dependencies → release-note risks → staging results → recovery test.

CREATE DATABASE IF NOT EXISTS servicehub_release_lab;CREATE TABLE servicehub_release_lab.version_gate (  dependency VARCHAR(40) PRIMARY KEY,  current_state VARCHAR(200) NOT NULL,  target_state VARCHAR(200) NOT NULL,  evidence_url VARCHAR(500) NULL,  validated TINYINT(1) NOT NULL DEFAULT 0,  notes VARCHAR(500) NULL) ENGINE=InnoDB;INSERT INTO servicehub_release_lab.version_gate(dependency,current_state,target_state,validated,notes) VALUES('server','local current build','12.3.2 LTS baseline',1,'Confirm again before production'),('connector','record actual driver','target-compatible',0,'Run integration tests'),('backup','record actual tool','restore-tested on target',0,'Restore is the acceptance test'),('plugins','inventory loaded plugins','all target-compatible',0,'Check package and docs');SELECT * FROM servicehub_release_lab.version_gate ORDER BY dependency;

7. Hands-on lab: make the current release decision observable

Run the version query against your local instance. Then compare the result with the official MariaDB Foundation “All releases” and “About MariaDB Server” lifecycle pages. Record the date you checked them. If your installed server is not 12.3.2, do not silently pretend that it is; write the actual build and decide whether you are using it for historical comparison or will install the current LTS in Lesson 4.

Verification checklist

• You recorded the exact server patch version and build comment.
• You identified the release maturity from an official source.
• You recorded Community maintenance/EOL information for the selected series.
• You listed connector, backup, plugin/engine, replication/Galera, and OS dependencies.
• You can explain one target-release default/behavior change that requires testing.

DROP DATABASE IF EXISTS servicehub_release_lab;

8. Production judgment: support windows are necessary, not sufficient

Choose a production baseline that has enough remaining support horizon for your organization’s patch and upgrade cadence, but do not select solely by EOL date. A release with a longer horizon can still be wrong if a required plugin is unavailable, an application depends on changed semantics, a managed provider lags the release, or your recovery tooling has not been validated.

At each planned upgrade, re-run the same decision process and preserve evidence. This chapter uses 12.3.2 because it is the current stable LTS at review time; later chapters should continue to verify the latest stable patch and security advisories instead of repeating 12.3.2 mechanically.

Authoritative references

• MariaDB Foundation — All releases
• MariaDB Foundation — About MariaDB Server / maintenance periods
• MariaDB Foundation — MariaDB Server 12.3 LTS released
• MariaDB Foundation — MariaDB 12.3/11.8/11.4/10.11/10.6 May 2026 releases
• MariaDB Documentation — Server System Variables