Run any Skill in Manus with one click

$pwd:

mariadb-core-version-matrix

Name: Mariadb Core Version Matrix
Author: Impertio-Studio

// Use when choosing which MariaDB version to install, upgrading between LTS releases, reasoning about feature availability, or interpreting EOL dates. Prevents the common mistake of assuming a feature works in 10.6 when it landed in 10.11, or running production on a non-LTS interim release. Covers LTS cadence (10.6 / 10.11 / 11.4 / 11.8 / next LTS), interim releases, EOL dates, breaking changes 10.6 to 10.11 to 11.x, feature-introduction matrix for top-30 features, upgrade-path with mariadb-upgrade. Keywords: mariadb version, LTS, 10.6, 10.11, 11.4, 11.8, 12, end of life, EOL, breaking change, feature matrix, when was X added, upgrade mariadb, mariadb-upgrade, mariadb_upgrade, version compatibility, jump version, which mariadb should I use, is feature X available, my version is old, support expired, production version

Run Skill in Manus

$ git log --oneline --stat

stars:1

forks:0

updated:May 19, 2026 at 23:35

File Explorer

4 files

SKILL.md

readonly

related-skills.json

same repository

mariadb-agents-query-optimizer.md

from "Impertio-Studio/MariaDB-Claude-Skill-Package"

Use when a user provides a slow query plus its EXPLAIN output and wants a concrete optimization, or asks "make this query faster", or wants an index recommendation validated against MariaDB optimizer behavior. Prevents the common mistake of suggesting an index without checking selectivity, proposing FORCE INDEX as a fix, copying MySQL 8 optimizer hints, or recommending an index that duplicates an existing one. Covers a deterministic query-optimization procedure : read EXPLAIN, identify the bottleneck (type=ALL, filesort, temporary), propose index or rewrite, validate against composite leftmost-prefix rule, check covering-index opportunity, verify with ANALYZE FORMAT=JSON, cross-references mariadb-impl-query-optimization, mariadb-syntax-indexing, mariadb-errors-slow-queries. Keywords: optimize my query, make this query faster, query optimization, EXPLAIN analysis, index recommendation, why is this slow, slow query fix, covering index, index suggestion, query rewrite, optimize SQL, performance fix, EXPLAIN, ANA

2026-05-191

mariadb-agents-schema-reviewer.md

from "Impertio-Studio/MariaDB-Claude-Skill-Package"

Use when reviewing a proposed MariaDB schema before it ships, auditing an existing schema for engine / indexing / naming / normalization problems, or validating a migration DDL. Prevents the common mistake of shipping a schema with MyISAM tables, UUID-text PKs, missing tenant indexes, utf8 charset, or composite indexes in the wrong column order. Covers a deterministic schema-review checklist : storage-engine choice, primary-key type, indexing strategy and column-order, charset / collation, normalization fitness, multi-tenant pattern detection, naming-convention adherence, with severity grading and cross-references to mariadb-core-storage-engines, mariadb-syntax-indexing, mariadb-impl-schema-design. Keywords: schema review, schema audit, review my schema, is this schema correct, schema checklist, design review, storage engine audit, index audit, primary key audit, normalization check, multi-tenant check, naming convention, DDL review, before I ship this schema, ENGINE=InnoDB, MyISAM, BIGINT AUTO_INCREMENT, UUI

2026-05-191

mariadb-errors-galera-conflicts.md

from "Impertio-Studio/MariaDB-Claude-Skill-Package"

Use when a Galera cluster reports certification failures, ER_LOCK_DEADLOCK fires at COMMIT in a multi-master setup, wsrep_local_cert_failures keeps climbing, a hot-row is contended across nodes, or the cluster appears to be in split-brain. Prevents the common mistake of treating Galera ER_LOCK_DEADLOCK as a bug, retrying without backoff, ignoring hot-row design, running a 2-node Galera without an arbitrator, or "fixing" symptoms by disabling wsrep_on. Covers certification-based replication semantics, ER_LOCK_DEADLOCK at COMMIT (Galera-specific path), wsrep_local_cert_failures and wsrep_local_bf_aborts status variables, hot-row detection plus sharding redesign, split-brain prevention with pc.weight and garbd, application retry strategy with exponential backoff, gcache exhaust leading to forced SST. Keywords: Galera, certification failure, wsrep_local_cert_failures, wsrep_local_bf_aborts, ER_LOCK_DEADLOCK at commit, ER_QUERY_INTERRUPTED, hot row, multi-master conflict, split brain, pc.weight, pc.ignore_sb, garb

2026-05-191

mariadb-impl-query-optimization.md

from "Impertio-Studio/MariaDB-Claude-Skill-Package"

Use when a query is slow, when reading EXPLAIN output, when deciding on index hints, when tuning optimizer_switch flags, when using optimizer_trace, or when comparing MariaDB and MySQL optimizer behavior. Prevents the common mistake of trusting type=ALL queries in production, blindly applying USE INDEX without checking selectivity, leaving outdated statistics, or copying MySQL 8 optimizer assumptions to MariaDB. Covers EXPLAIN reading column-by-column, EXPLAIN FORMAT=JSON, ANALYZE FORMAT=JSON (actual execution stats), index hints USE/FORCE/IGNORE INDEX, optimizer_switch flags (MariaDB-specific), optimizer_trace, ANALYZE TABLE for statistics, persistent vs in-memory statistics. Keywords: EXPLAIN, EXPLAIN FORMAT JSON, ANALYZE FORMAT JSON, query plan, optimizer, optimizer_switch, optimizer_trace, USE INDEX, FORCE INDEX, IGNORE INDEX, type ALL, type ref, type range, key_len, rows, filtered, Using filesort, Using temporary, Using index, ANALYZE TABLE, persistent statistics, why is my query slow, slow query, query

2026-05-191

mariadb-syntax-sql-dml.md

from "Impertio-Studio/MariaDB-Claude-Skill-Package"

Use when writing INSERT, UPDATE, DELETE, REPLACE, or upsert statements, debugging "why was this row not updated", or migrating MySQL DML patterns to MariaDB. Prevents the INSERT IGNORE silent-corruption trap, REPLACE INTO FK cascade, ON DUPLICATE KEY auto-increment burn, multi-table UPDATE/DELETE ordering pitfalls, and the "UPDATE RETURNING does not exist in LTS" gotcha. Covers INSERT single-row + multi-row + INSERT SET + INSERT ... SELECT, INSERT ... ON DUPLICATE KEY UPDATE, INSERT IGNORE pitfalls, REPLACE INTO, UPDATE ... ORDER BY ... LIMIT, multi-table UPDATE/DELETE with JOIN, INSERT/DELETE RETURNING, DELETE HISTORY for system-versioned tables. Keywords: INSERT, UPDATE, DELETE, REPLACE, ON DUPLICATE KEY UPDATE, INSERT IGNORE, RETURNING, INSERT RETURNING, DELETE RETURNING, multi-table UPDATE, multi-table DELETE, upsert, why was my row not updated, my insert ignored the error, auto increment burn, FK cascade on REPLACE, mariadb upsert pattern, UPDATE RETURNING not supported, DELETE HISTORY, system-versioned

2026-05-191

mariadb-core-defaults-and-sql-modes.md

from "Impertio-Studio/MariaDB-Claude-Skill-Package"

Use when investigating "my query worked yesterday and now doesn't", upgrading between LTS releases, migrating from MySQL, or setting up a new MariaDB instance with explicit sql_mode and charset. Prevents the common mistake of relying on implicit defaults that change between versions, mixing sql_mode-strict with legacy data, or assuming utf8 means utf8mb4. Covers sql_mode per version (STRICT_TRANS_TABLES, ANSI_QUOTES, NO_ZERO_DATE, etc.), default server charset_set_server shift from latin1 to utf8mb4 in 11.6, default utf8mb4 collation shift to utf8mb4_uca1400_ai_ci in 11.5, default authentication plug-in evolution, default storage engine (InnoDB), default binlog format MIXED since 10.2.3, my.cnf defaults that break apps on upgrade. Keywords: mariadb defaults, sql_mode, STRICT_TRANS_TABLES, ANSI_QUOTES, default charset, utf8mb4, utf8mb4_uca1400, default authentication, default storage engine, my.cnf defaults, why does this query fail now, upgrade broke my app, sql mode change between versions, NO_ZERO_DATE, ONL

2026-05-191

package.json

"author": "Impertio-Studio"

"repository": "Impertio-Studio/MariaDB-Claude-Skill-Package"

View GitHub Repository View Creator Repositories

$ install --global

$ download --local

Run Skill in Manus

$ useful --forSOC

Network and Computer Systems AdministratorsComputer and Mathematical Occupations15-1244L4

name	mariadb-core-version-matrix
description	Use when choosing which MariaDB version to install, upgrading between LTS releases, reasoning about feature availability, or interpreting EOL dates. Prevents the common mistake of assuming a feature works in 10.6 when it landed in 10.11, or running production on a non-LTS interim release. Covers LTS cadence (10.6 / 10.11 / 11.4 / 11.8 / next LTS), interim releases, EOL dates, breaking changes 10.6 to 10.11 to 11.x, feature-introduction matrix for top-30 features, upgrade-path with mariadb-upgrade. Keywords: mariadb version, LTS, 10.6, 10.11, 11.4, 11.8, 12, end of life, EOL, breaking change, feature matrix, when was X added, upgrade mariadb, mariadb-upgrade, mariadb_upgrade, version compatibility, jump version, which mariadb should I use, is feature X available, my version is old, support expired, production version
license	MIT
compatibility	Designed for Claude Code. Requires MariaDB 10.6-LTS, 10.11-LTS, 11.x, 12.x.
metadata	{"author":"OpenAEC-Foundation","version":"1.0"}

MariaDB Core : Version Matrix

Authoritative guide to MariaDB version selection, feature-availability, EOL dates and upgrade procedure. Use this skill whenever a question depends on "is feature X in version Y" or "should I run 10.11 or 11.4 in production".

Quick Reference

ALWAYS pick an LTS release for production : 10.6 / 10.11 / 11.4 / 11.8 / next.

ALWAYS treat interim releases (10.x.y between LTS, 11.0, 11.1, 11.2, 11.3, 11.5, 11.6, 11.7, 12.0) as short-support, dev-only.

ALWAYS run mariadb-upgrade after every binary swap (in-place upgrade).

ALWAYS upgrade one major version at a time. NEVER jump 10.6 directly to 11.4 or 11.8. Path is 10.6 to 10.11, then 10.11 to 11.4, then 11.4 to 11.8.

ALWAYS query SELECT VERSION(); on the live server before asserting a feature works. Distro version-labels (apt-cache policy mariadb-server) lag the real server VERSION().

ALWAYS check the per-feature row in references/methods.md before writing code that uses a feature added after 10.6 ; many production fleets are still on 10.6 LTS through mid-2026.

NEVER trust dev.mysql.com docs for MariaDB feature availability. MariaDB and MySQL diverged after MariaDB 5.5, and several features (sequences, system-versioned tables, RETURNING, dynamic columns, application-time periods, INVISIBLE columns, IGNORED indexes, MariaDB JSON-as-LONGTEXT) are MariaDB-only or differ semantically.

NEVER run mariadb-upgrade twice in a row. It is idempotent but the second pass logs noise that masks real errors from the first.

NEVER run a beta or RC of the next-LTS in production. Wait for the LTS GA tag.

NEVER mix MariaDB major versions inside a single Galera cluster. The cluster-protocol guarantees behavior only within one major series.

LTS Cadence at a Glance

Version	GA Date	Community EOL	Status	When to pick
10.6	2021-07-06	2026-07-06	LTS, last 12 months	Frappe v14/v15 baseline ; legacy Frappe ; mature 10.x deployments
10.11	2023-02-16	2028-02-16	LTS, active	Conservative production default in 2025-2026
11.4	2024-05-29	2029-05-29	LTS, active	Modern production default in 2026+
11.8	2025-06-04	2028-06-04	LTS, newest	New deployments ; Frappe v16 baseline
12.x	TBD	TBD	Interim until LTS	Dev only ; wait for the LTS designation

Each LTS gets ~5 years of community support. Enterprise and Extended support extend beyond that ; use the source URLs in references/methods.md for exact dates per tier.

Interim releases (10.7, 10.8, 10.9, 10.10 ; 11.0, 11.1, 11.2, 11.3, 11.5, 11.6, 11.7 ; 12.0) get ~1 year of community support each. They are testbeds for the next LTS, not production targets.

Decision Trees

Which LTS version should I install in 2026?

New deployment with no constraints?
  -> 11.4 LTS (conservative) or 11.8 LTS (newest)

Running Frappe v14 or v15?
  -> 10.6 LTS minimum, 10.11 LTS recommended

Running Frappe v16 or develop?
  -> 11.8 LTS (hard floor)

Migrating from MySQL 5.7/8.0?
  -> 10.11 LTS (drop-in compatibility path)
  -> 11.4 or 11.8 only after read-replica burn-in

Legacy 10.4 or 10.5 in production today?
  -> Already EOL ; upgrade to 10.6 ASAP, then to 10.11 within 12 months

Is feature X available in my MariaDB version?

Run SELECT VERSION(); on the live server (not your laptop, not docker-compose)
Look up X in references/methods.md "Feature-Introduction Matrix"
Cell shows first version that ships the feature

VERSION() >= matrix-cell ? -> feature available
VERSION() <  matrix-cell ? -> feature absent ; do NOT generate code that uses it

For runtime detection (programmatic), do
  SELECT @@version AS v, @@version_compile_os AS os;
or for specific feature flags
  SELECT @@have_query_cache; (returns YES/NO)

Should I upgrade from 10.6 to 11.4 in one step?

NEVER. Always one major at a time. Path :

10.6 LTS -> 10.11 LTS  (run mariadb-upgrade)
10.11 LTS -> 11.4 LTS  (run mariadb-upgrade)
11.4 LTS -> 11.8 LTS   (run mariadb-upgrade)

Reasons : mysql.global_priv schema, default authentication plugin, default collation and tool renames each shift between majors. Multi-step jumps stack incompatibilities the upgrade tool was not designed to resolve in a single pass.

In-place upgrade vs dump-and-restore : which one?

Same major series (e.g. 10.6.18 -> 10.6.21)?
  -> In-place. Stop server, install new binaries, start server, run mariadb-upgrade.

One major step (e.g. 10.6 -> 10.11)?
  -> In-place. Same procedure. Schedule downtime ; mariadb-upgrade may take minutes
     on large mysql.* system tables.

Two-or-more major steps (e.g. 10.6 -> 11.4)?
  -> Do it as a sequence of one-step in-place upgrades, OR
  -> Dump-and-restore from 10.6 directly into a fresh 11.4 install. The dump path
     avoids cumulative system-table cruft but costs full downtime equal to dump+restore.

Cross-cluster (Galera, replication)?
  -> Rolling : upgrade one node at a time, but only within one major series.
     Cross-major requires a full cluster shutdown.

Patterns

Pattern 1 : Detect the running version before code-generation

When generating SQL that might depend on a version-specific feature, capture the running version first :

-- Run on the target server, never assume
SELECT
  VERSION()                AS full_version,    -- e.g. 11.4.4-MariaDB
  @@version_compile_os     AS os,              -- e.g. Linux
  @@innodb_version         AS innodb_version;

Then compare against the Feature-Introduction Matrix in references/methods.md and emit code only for features present in that version.

Pattern 2 : In-place binary upgrade

# 1) Backup first (mandatory, never skip)
mariadb-dump --all-databases --single-transaction --routines --triggers --events \
  --master-data=2 > /backup/pre-upgrade-$(date +%F).sql

# 2) Stop the old server
systemctl stop mariadb

# 3) Install the new binaries (distro-specific)
apt-get install mariadb-server=10.11.*    # or 11.4.*, 11.8.*

# 4) Start the new server
systemctl start mariadb

# 5) Run the upgrade tool ONCE
mariadb-upgrade --user=root --password
# (10.5+ binary ; on 10.4 and older it is named mysql_upgrade)

# 6) Verify
mariadb -e "SELECT VERSION(); SHOW WARNINGS;"

Pattern 3 : Dump-and-restore upgrade for big version jumps

# 1) Logical dump from old server (10.6)
mariadb-dump --all-databases --single-transaction --routines --triggers --events \
  --hex-blob --max-allowed-packet=1G > /backup/full.sql

# 2) Provision a fresh server (e.g. 11.4 LTS) with empty datadir
# 3) Restore into the fresh server
mariadb --max-allowed-packet=1G < /backup/full.sql

# 4) Run mariadb-upgrade on the new server (idempotent ; harmless on fresh install)
mariadb-upgrade --user=root --password

# 5) Verify row counts per critical table match the pre-dump source

Pattern 4 : Feature-detection at application boot

-- Detect JSON_TABLE (10.6+) availability without a try-catch
SELECT COUNT(*) AS supports_json_table
FROM information_schema.routines
WHERE routine_schema = 'mysql' AND routine_name = 'JSON_TABLE';

-- Detect window-function support (10.2+)
SELECT @@have_innodb;  -- general sanity ; for window/CTE detect via SELECT VERSION()

-- Detect sequences (10.3+, MariaDB-only)
SELECT COUNT(*) AS supports_sequences
FROM information_schema.tables
WHERE table_schema = 'information_schema' AND table_name = 'SEQUENCES';

What This Skill Does NOT Cover

Detailed migration from MySQL to MariaDB : see mariadb-impl-migration-mysql-to-mariadb
Replication / Galera architecture : see mariadb-core-replication-model
Storage-engine selection : see mariadb-core-storage-engines
Per-feature SQL syntax : see the corresponding mariadb-syntax-* skill

Reference Links

references/methods.md : full LTS / EOL table, complete feature-introduction matrix, breaking-changes-per-major table, mariadb-upgrade tool reference
references/examples.md : 10 worked examples (version detection, in-place upgrade, dump-and-restore, feature detection, rollback strategy)
references/anti-patterns.md : 10 anti-patterns with WHY-it-fails and the correct alternative

Sources

All facts in this skill are verified against :

https://mariadb.org/about/#maintenance-policy (LTS / EOL table, verified 2026-05-19)
https://mariadb.com/kb/en/release-notes/ (per-version release notes index)
https://mariadb.com/kb/en/about-mariadb-server/ (cadence and versioning)
https://mariadb.com/kb/en/upgrading/ (mariadb-upgrade procedure)
https://mariadb.com/kb/en/mariadb-vs-mysql-features/ (feature divergence)

See references/methods.md for the per-row source citation behind every feature entry in the matrix.

mariadb-core-version-matrix

More from this repository

MariaDB Core : Version Matrix

Quick Reference

LTS Cadence at a Glance

Decision Trees

Which LTS version should I install in 2026?

Is feature X available in my MariaDB version?

Should I upgrade from 10.6 to 11.4 in one step?

In-place upgrade vs dump-and-restore : which one?

Patterns

Pattern 1 : Detect the running version before code-generation

Pattern 2 : In-place binary upgrade

Pattern 3 : Dump-and-restore upgrade for big version jumps

Pattern 4 : Feature-detection at application boot

What This Skill Does NOT Cover

Reference Links

Sources

MariaDB Core : Version Matrix

Quick Reference

LTS Cadence at a Glance

Decision Trees

Which LTS version should I install in 2026?

Is feature X available in my MariaDB version?

Should I upgrade from 10.6 to 11.4 in one step?

In-place upgrade vs dump-and-restore : which one?

Patterns

Pattern 1 : Detect the running version before code-generation

Pattern 2 : In-place binary upgrade

Pattern 3 : Dump-and-restore upgrade for big version jumps

Pattern 4 : Feature-detection at application boot

What This Skill Does NOT Cover

Reference Links

Sources

More from this repository