MySQL to MariaDB 11 Migration Guide 2026: Escape Oracle Lock-in

Key Takeaways

• Drop-in replacement: MariaDB reads MySQL config files, uses the same client protocol, and requires no application code changes for most workloads.
• Test on staging first: Dump your MySQL database, restore into MariaDB on a staging server, run your full test suite before touching production.
• Check authentication plugin: MySQL 8 defaults to caching_sha2_password; MariaDB uses ed25519 or mysql_native_password. Update app connection strings accordingly.
• Sovereign from day one: MariaDB is GPL-licensed, maintained by the MariaDB Foundation, with zero Oracle involvement. No proprietary enterprise-only features needed for production use.

---

Introduction

Direct Answer: How do I migrate from MySQL 8 to MariaDB 11 on Ubuntu 24.04 in 2026?

The migration is a dump-and-restore: export from MySQL with mysqldump -u root -p --all-databases --single-transaction --routines --triggers --events > mysql-backup.sql, stop MySQL (sudo systemctl stop mysql), install MariaDB 11 (sudo apt-get install mariadb-server), start MariaDB (sudo systemctl start mariadb), import the dump (sudo mariadb < mysql-backup.sql), and run sudo mariadb-upgrade to update system tables. Total time: 15–60 minutes depending on database size. Test on a staging server first: the vast majority of MySQL 8 SQL, procedures, and triggers work identically in MariaDB 11, but verify your specific workload before cutting over production.

---

Part 1: Pre-Migration Compatibility Check

# On the MySQL server — check what features you're using
sudo mysql << 'SQL'
-- Check authentication plugins in use (may need to change in app connection strings)
SELECT user, host, plugin FROM mysql.user WHERE plugin != 'mysql_native_password';

-- Check for MySQL 8-specific JSON functions that differ in MariaDB
SELECT ROUTINE_NAME FROM information_schema.ROUTINES
WHERE ROUTINE_BODY LIKE '%JSON_TABLE%'
   OR ROUTINE_BODY LIKE '%ROLE%'
   OR ROUTINE_BODY LIKE '%INVISIBLE%';

-- Check storage engines in use
SELECT ENGINE, COUNT(*) FROM information_schema.TABLES
WHERE TABLE_SCHEMA NOT IN ('information_schema','mysql','performance_schema','sys')
GROUP BY ENGINE;

-- Database sizes
SELECT table_schema AS 'Database',
       ROUND(SUM(data_length + index_length) / 1024 / 1024, 0) AS 'Size (MB)'
FROM information_schema.TABLES
GROUP BY table_schema
ORDER BY 2 DESC;
SQL

Expected output:

user     host      plugin
root     localhost  auth_socket
webapp   localhost  mysql_native_password

ENGINE   COUNT(*)
InnoDB   47

Good: all tables use InnoDB (fully compatible with MariaDB). mysql_native_password requires no changes.

---

Part 2: Export from MySQL

# Create backup directory
sudo mkdir -p /var/backups/migration
cd /var/backups/migration

# Full export (use --single-transaction for consistent InnoDB backup)
sudo mysqldump \
    -u root \
    --single-transaction \
    --routines \
    --triggers \
    --events \
    --all-databases \
    --add-drop-database \
    --flush-logs \
    > mysql-full-export.sql

# Verify the export
wc -l mysql-full-export.sql
head -5 mysql-full-export.sql
tail -3 mysql-full-export.sql

Expected output:

1847293 mysql-full-export.sql
-- MySQL dump 10.13  Distrib 8.0.36, for Linux (x86_64)
-- Host: localhost    Database:
-- ------------------------------------------------------
...
-- Dump completed on 2026-05-01  8:00:00

---

Part 3: Install MariaDB 11

# Add MariaDB official repository (newer than Ubuntu's package)
curl -fsSL https://downloads.mariadb.com/MariaDB/mariadb_repo_setup | \
    sudo bash -s -- --mariadb-server-version="mariadb-11.4"

sudo apt-get update
sudo apt-get install -y mariadb-server mariadb-client

mariadb --version

Expected output:

mariadb  Ver 15.1 Distrib 11.4.3-MariaDB, for debian-linux-gnu (x86_64)

# Secure the installation
sudo mariadb-secure-installation
# Answer: n (no socket auth change), Y (remove anon users), Y (disallow root remote), Y (remove test db), Y (reload)

---

Part 4: Import into MariaDB

# Import the MySQL dump
sudo mariadb < /var/backups/migration/mysql-full-export.sql

# Run upgrade check (updates system tables for MariaDB 11 format)
sudo mariadb-upgrade -u root -p

Expected output:

Phase 1/7:   Checking and upgrading mysql database
Processing databases
mysql
mysql.column_stats                     OK
mysql.columns_priv                     OK
...
Phase 7/7:   Running 'FLUSH PRIVILEGES'
OK

# Verify databases migrated correctly
sudo mariadb -u root -p -e "SHOW DATABASES; SELECT COUNT(*) FROM mysql.user;"

# Verify table counts match MySQL source
sudo mariadb -u root -p -e "
SELECT table_schema, COUNT(*) AS tables
FROM information_schema.TABLES
WHERE table_schema NOT IN ('information_schema','mysql','performance_schema','sys')
GROUP BY table_schema;"

---

Part 5: Recreate Application Users

-- MariaDB 11 user creation (same syntax as MySQL)
CREATE USER 'webapp'@'localhost' IDENTIFIED BY 'strongpassword';
GRANT SELECT, INSERT, UPDATE, DELETE ON appdb.* TO 'webapp'@'localhost';
FLUSH PRIVILEGES;

-- Verify
SHOW GRANTS FOR 'webapp'@'localhost';

---

Part 6: Update Application Connection Strings

# Python (PyMySQL / mysql-connector-python — both work with MariaDB)
# No changes needed for most drivers — just update host if different

import pymysql
conn = pymysql.connect(
    host='localhost',
    user='webapp',
    password='strongpassword',
    database='appdb',
    # MariaDB uses mysql_native_password by default — no auth_plugin needed
)

# SQLAlchemy
from sqlalchemy import create_engine
engine = create_engine('mysql+pymysql://webapp:strongpassword@localhost/appdb')
# MariaDB also supports: 'mariadb+mariadbconnector://...' for the native connector

# Test application connection
python3 -c "
import pymysql
conn = pymysql.connect(host='localhost', user='webapp', password='strongpassword', database='appdb')
cursor = conn.cursor()
cursor.execute('SELECT VERSION()')
print('MariaDB version:', cursor.fetchone()[0])
cursor.execute('SELECT COUNT(*) FROM users')
print('User count:', cursor.fetchone()[0])
"

Expected output:

MariaDB version: 11.4.3-MariaDB
User count: 4847

---

Part 7: Performance Tuning (MariaDB 11)

sudo tee /etc/mysql/mariadb.conf.d/99-performance.cnf << 'EOF'
[mysqld]
# InnoDB — same tuning as MySQL
innodb_buffer_pool_size    = 2G       # 25% of RAM for 8GB server
innodb_log_file_size       = 512M
innodb_flush_log_at_trx_commit = 1   # Safest for ACID
innodb_flush_method        = O_DIRECT

# MariaDB-specific: Thread pool (replaces MySQL Enterprise thread pool)
thread_handling            = pool-of-threads
thread_pool_size           = 8        # Number of vCPUs

# Query cache (removed in MySQL 8, still available in MariaDB 11)
# Disable for write-heavy workloads:
query_cache_size           = 0
query_cache_type           = 0

# Slow query log
slow_query_log             = 1
slow_query_log_file        = /var/log/mysql/slow.log
long_query_time            = 1
EOF

sudo systemctl restart mariadb
sudo mariadb -u root -p -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size';"

---

MariaDB 11 vs MySQL 8: Feature Comparison

Feature	MySQL 8	MariaDB 11
Licence	GPL (Community) / Proprietary (Enterprise)	GPL only
Oracle involvement	Yes	No
Thread pool	Enterprise only	Built-in (free)
Galera multi-master	No	Built-in
Query cache	Removed	Available
SHOW EXPLAIN	No	Yes
JSON support	Full	Full (compatible)
Window functions	Yes	Yes
CTEs	Yes	Yes
Default auth plugin	caching_sha2_password	ed25519 / mysql_native_password

---

Troubleshooting

Authentication plugin 'caching_sha2_password' cannot be loaded

MySQL 8 exported user with caching_sha2_password which MariaDB doesn’t support. Fix: In the SQL dump, find lines like IDENTIFIED WITH 'caching_sha2_password' and change to IDENTIFIED BY 'password'. Or re-create the user manually in MariaDB.

Import fails on SET @@SESSION.SQL_LOG_BIN

Some MySQL 8 dumps include replication-specific SET statements MariaDB ignores or errors on. Fix: grep -v "SQL_LOG_BIN" mysql-full-export.sql | sudo mariadb

Application shows Unknown collation: 'utf8mb4_0900_ai_ci'

MySQL 8 uses utf8mb4_0900_ai_ci as default; MariaDB uses utf8mb4_general_ci. Fix: sed -i 's/utf8mb4_0900_ai_ci/utf8mb4_general_ci/g' mysql-full-export.sql before importing.

---

Conclusion

MariaDB 11 is running with your MySQL data migrated — identical wire protocol, same client libraries, better open-source governance. The dump-and-restore approach is safe, testable on staging, and reversible. MariaDB’s Thread Pool (free) and Galera Cluster (free) deliver features that require MySQL Enterprise ($) subscriptions.

See How to Install MySQL 9 on Ubuntu 24.04 for MySQL reference, and PostgreSQL 17 Performance Tuning for the alternative sovereign RDBMS.

---

People Also Ask

Is MariaDB fully compatible with MySQL applications?

For the vast majority of applications: yes. MariaDB uses the same wire protocol (MySQL clients connect without changes), the same SQL dialect, and the same my.cnf configuration format. Applications using SQLAlchemy, Django ORM, Hibernate, Eloquent, and other ORMs work without changes. Edge cases to check: MySQL 8-specific JSON functions (JSON_TABLE, JSON_SCHEMA_VALID), caching_sha2_password authentication, and any use of MySQL Enterprise features (InnoDB Cluster, Group Replication). For standard CRUD applications, e-commerce, and CMS platforms: compatibility is effectively 100%.

Should I use MariaDB or PostgreSQL for a new project in 2026?

For new projects with no MySQL history: PostgreSQL is the stronger technical choice — better standards compliance, richer data types (JSONB, arrays, hstore), more powerful indexing, and stronger ACID guarantees for complex transactions. MariaDB’s advantage is MySQL compatibility — if you have existing MySQL applications, teams, or tooling, MariaDB gives you an Oracle-free path without application changes. See the full comparison at PostgreSQL vs MySQL 2026.

---

Part 5: MariaDB 11 Performance Tuning

MariaDB 11 includes optimisations that differ slightly from MySQL 8. Tune innodb_buffer_pool_size, thread_pool_size, and query cache settings to your workload.

5.1 InnoDB buffer pool sizing

MariaDB uses InnoDB for most workloads. Set innodb_buffer_pool_size to roughly 50-70% of available RAM on a dedicated database server. For example, on an 8GB machine:

[mysqld]
innodb_buffer_pool_size=4G
innodb_buffer_pool_instances=4
innodb_flush_method=O_DIRECT
innodb_log_file_size=1G

Using O_DIRECT avoids double buffering and is standard for production.

5.2 Thread pool and connection handling

MariaDB’s thread pool can improve concurrency under many connections. Use thread_handling=pool-of-threads and set a modest thread pool size.

thread_handling=pool-of-threads
thread_pool_size=16
thread_pool_max_threads=64

For smaller systems, one-thread-per-connection works, but it can cost more memory.

5.3 Adaptive hash index and temporary tables

MariaDB’s adaptive hash index is useful for read-heavy workloads. Enable it unless you are hitting high contention.

innodb_adaptive_hash_index=ON
innodb_temp_data_file_path=ibtmp1:12M:autoextend:max:5G

Temporary tables on disk should be limited for high-volume query workloads.

5.4 Query cache and optimizer hints

While MySQL deprecated query cache, MariaDB still supports it on some engines. For most modern workloads, keep query cache disabled and rely on buffer pool caching.

query_cache_type=0
query_cache_size=0

Use EXPLAIN and OPTIMIZER_TRACE to diagnose slow SQL and tuning.

Part 6: High Availability and Clustering Options

MariaDB can run in several high-availability topologies. Choose the one that matches your sovereignty goals.

6.1 Primary/standby with replication

The simplest HA model is async replication from a primary MySQL/MariaDB server to one or more standbys. It is easy to set up and works well for read-scaling and quick failover.

Take a snapshot, use CHANGE MASTER TO, and keep replication under supervision with SHOW SLAVE STATUS\G.

6.2 Galera multi-master clustering

Galera offers synchronous replication across nodes. It is powerful, but it requires consistent network latency and careful configuration.

On Ubuntu 24.04, install galera-4 and MariaDB 11 with the cluster package, then configure:

[mysqld]
wsrep_on=ON
wsrep_provider=/usr/lib/galera/libgalera_smm.so
wsrep_cluster_address="gcomm://db1.example.com,db2.example.com,db3.example.com"
wsrep_node_address=db1.example.com
wsrep_cluster_name="mariadb-cluster"
wsrep_sst_method=rsync

Use Galera for local clusters when you need fast failover and multi-master writes. Keep wsrep_provider_options='gcache.size=1G' to avoid re-sending large transactions.

6.3 Backup strategies for clustered setups

For Galera, prefer physical backups with mariabackup and consistent SST methods. For primary/standby, regular mysqldump or mariabackup plus binary log retention is enough.

6.4 Choosing the right HA model

• Use primary/standby if you need simplicity and realistic recovery time.
• Use Galera if you need multi-master writes and your network is reliable.
• Use standalone MariaDB if your workload is small and you want lower operational overhead.

Part 7: Monitoring and Observability

Self-hosted database sovereignty includes monitoring the database stack locally.

7.1 Metrics to collect

Monitor:

• queries per second
• slow queries
• InnoDB buffer pool hit rate
• replication lag
• disk latency
• CPU and memory usage

MariaDB exposes these via SHOW GLOBAL STATUS and performance_schema.

7.2 Prometheus and Grafana

For an observability stack, use Prometheus and Grafana locally. The mysqld_exporter can scrape MariaDB metrics.

docker run -d --name mysqld-exporter   -e DATA_SOURCE_NAME="user:pass@(localhost:3306)/"   prom/mysqld-exporter:latest

Then configure Prometheus to scrape /metrics from the exporter.

7.3 Log monitoring

Keep error.log, slow-query.log, and general.log under local retention. Use pt-query-digest for slow query analysis.

pt-query-digest /var/log/mysql/slow-query.log > /var/reports/slow-report.txt

Monitor for long-running DDL, high lock contention, and repeated failed connections.

Part 8: MariaDB-Specific SQL Differences

While MariaDB is a MySQL drop-in replacement, some SQL dialect differences matter.

8.1 Authentication plugin differences

MySQL 8 defaults to caching_sha2_password; MariaDB 11 prefers ed25519 or mysql_native_password.

CREATE USER 'app'@'localhost' IDENTIFIED VIA ed25519 USING 'passwordhash';

If your application driver cannot handle ed25519, use mysql_native_password instead.

8.2 JSON function compatibility

MariaDB has a different JSON syntax and some function names differ. For example:

• In MySQL: JSON_TABLE()
• In MariaDB: JSON_TABLE() exists but with different semantics for nested path expressions

Test your JSON queries carefully.

8.3 Window functions and CTEs

Most modern MySQL window functions work in MariaDB, but edge cases may differ. Use SHOW WARNINGS after complex queries.

8.4 Storage engine differences

MariaDB includes engines such as Aria, MyRocks, and Spider. Stick with InnoDB for compatibility unless you need a specific engine.

Part 9: Migration Testing Checklist

Before switching production, verify your migration with these checks:

• Full data export completed successfully
• Staging import validated with the same schema and row counts
• Application-level smoke tests passed
• SHOW TABLES and CHECK TABLE return OK for all databases
• Stored procedures, triggers, and events are intact
• Connections from app servers succeed with MariaDB credentials
• Slow query logs show no new performance regressions
• Backup and restore tested on MariaDB

Part 10: Rollback and Recovery

A good migration includes a rollback plan.

10.1 Keep the original MySQL server available

Do not delete the MySQL server until MariaDB has run in production for at least one full backup cycle.

10.2 Rewind to MySQL if needed

If you need to roll back, restore from the MySQL dump or use the original MySQL instance. Keep the old connection strings and credentials unchanged until you complete the cutover.

10.3 Document the migration

Capture:

• exact commands used
• exported file names and checksums
• MariaDB configuration changes
• any SQL incompatibilities found
• test results and production cutover time

This document is the final sovereign asset for the migration.

Part 11: Production Hardening

After migration, lock down the MariaDB server with these practices:

• disable remote root login
• remove anonymous users
• restrict user access to necessary schemas
• use TLS for client connections when possible
• limit open connections with max_connections
• keep backups separate from the database host
• store all MariaDB packages in a private repository if offline updates are needed

A sovereign database stack is not just open-source; it is auditable, repeatable, and recoverable.

Part 12: Application Compatibility and Edge Cases

Even though MariaDB is largely MySQL-compatible, the edge cases matter for robust sovereign migrations.

12.1 Stored routines and DEFINER clauses

MariaDB preserves stored routines, but DEFINERs can cause permission issues after migration. Search your dump for DEFINER= and update it if the original account no longer exists.

grep -R "DEFINER=" /var/backups/migration/mysql-full-export.sql | head

If needed, use sed to remove DEFINER clauses before importing:

sed -i 's/DEFINER=[^*]*\*/\*/g' mysql-full-export.sql

Then import again.

12.2 Trigger and event compatibility

Triggers and events usually migrate cleanly, but verify that your event scheduler is enabled:

SHOW VARIABLES LIKE 'event_scheduler';
SET GLOBAL event_scheduler = ON;

If you rely on frequent scheduled jobs, monitor the event scheduler after cutover.

12.3 Collation and charset differences

MariaDB 11 can behave differently with utf8mb4 collations. Check the character set of your columns and use the same collation if possible.

SELECT table_schema, table_name, column_name, character_set_name, collation_name
FROM information_schema.COLUMNS
WHERE table_schema NOT IN ('information_schema','mysql','performance_schema','sys');

Avoid changing collation during migration unless you have a good reason.

12.4 JSON path and indexing

MariaDB’s JSON indexing and function support differs from MySQL. If you use JSON path expressions heavily, test them thoroughly.

For performance, create generated columns and indexes when needed:

ALTER TABLE docs ADD COLUMN title VARCHAR(255) AS (json_extract(payload, '$.title')) STORED;
CREATE INDEX idx_docs_title ON docs (title);

Part 13: MariaDB Security Hardening

MariaDB has the same security surface as MySQL plus some MariaDB-specific features.

13.1 Secure plugin configuration

Disable unneeded authentication plugins and remove anonymous accounts.

DELETE FROM mysql.user WHERE user = '';
DELETE FROM mysql.user WHERE user = 'root' AND host != 'localhost';
FLUSH PRIVILEGES;

13.2 TLS for client connections

Protect remote connections with TLS.

[mysqld]
ssl_cert=/etc/mysql/ssl/server-cert.pem
ssl_key=/etc/mysql/ssl/server-key.pem
ssl_ca=/etc/mysql/ssl/ca.pem

Require TLS for remote application users:

ALTER USER 'app'@'%' REQUIRE X509;

13.3 Local network segmentation

Keep database traffic on a private VLAN or subnet. Do not expose MariaDB to the public internet unless absolutely necessary.

13.4 Auditing and logs

Enable the MariaDB audit plugin if you need a local audit trail.

[mysqld]
audit_log=ON
audit_log_file=/var/log/mysql/audit.log
audit_log_format=JSON

This adds local accountability without sending logs to a remote service.

Part 14: Long-Term Maintenance

A migration is not complete until maintenance is established.

14.1 Upgrade policy

Plan MariaDB minor upgrades with a maintenance window and a rollback image. Keep the package repository pinned to MariaDB 11.4 if you need stability.

14.2 Backup validation

Restore at least one backup each quarter to a test host. A backup is only reliable if it has been restored successfully.

14.3 Performance review

Review slow queries monthly after migration. Use performance_schema and slow-query.log to identify regressions.

14.4 Documentation

Maintain a local migration document with:

• cutover commands
• configuration changes
• application compatibility notes
• rollback instructions

This is the sovereign record of the migration.

Part 15: Schema Change and Migration Management

In a sovereign database migration, schema management is as important as data migration.

15.1 Version-controlled schema changes

Keep your DDL in version control alongside application code. Use ALTER TABLE scripts with explicit IF EXISTS guards and a rollback plan.

15.2 Zero-downtime migration patterns

For large tables, use a shadow table pattern:

1. create a new table with the updated schema
2. copy existing rows in batches
3. apply ongoing changes from binlog or triggers
4. swap tables with minimal downtime

This is safer than an immediate ALTER TABLE on a heavy production table.

15.3 Testing DDL in staging

Run every schema migration in a staging environment that mirrors production. Verify indexes, constraints, and growth characteristics before applying to the live database.

Part 16: Performance Diagnostics and Tools

Use performance_schema, mysqladmin, and MariaDB-specific tools to find hot spots.

16.1 Using mysqladmin and mariadb-admin

mysqladmin status
mysqladmin processlist

These commands show query load, thread counts, and long-running statements.

16.2 Performance schema events

Enable the performance schema and query it for I/O, waits, and statement latency.

SELECT event_name, COUNT_STAR, SUM_TIMER_WAIT 
FROM performance_schema.events_statements_summary_by_digest
ORDER BY SUM_TIMER_WAIT DESC
LIMIT 20;

16.3 Inspecting optimizer decisions

Use EXPLAIN FORMAT=JSON to see how MariaDB plans queries. Compare the plan in MySQL and MariaDB for critical workloads.

Part 17: Backup Restore Workflow Example

A reliable recovery workflow is essential.

17.1 Daily physical backups

Use mariabackup for consistent physical backups.

sudo mariabackup --backup --target-dir=/var/backups/mariadb/$(date +%F)     --user=backup --password='backupsecret'

17.2 Restore to test host

sudo mariabackup --prepare --target-dir=/var/backups/mariadb/2026-05-22
sudo systemctl stop mariadb
sudo rm -rf /var/lib/mysql/*
sudo mariabackup --copy-back --target-dir=/var/backups/mariadb/2026-05-22
sudo chown -R mysql:mysql /var/lib/mysql
sudo systemctl start mariadb

Test that the restored instance starts and that the application can connect.

17.3 Restore validation

Run SHOW TABLES, a sample query, and your app smoke tests after every restore.

Part 18: MariaDB Feature Audit

MariaDB 11 introduces features beyond MySQL. Audit them for production use.

18.1 Spider and Aria engines

These are useful for specific cases, but they add complexity. Use them only when you need distributed storage or complex temporary table behavior.

18.2 System versioned tables

MariaDB supports system-versioned temporal tables. They are powerful but should be used intentionally.

CREATE TABLE employees (
    id INT PRIMARY KEY,
    name VARCHAR(255),
    salary DECIMAL(10,2),
    SYSTEM VERSIONING
);

18.3 Enterprise compatibility notes

Some MariaDB enterprise features are not part of the open source edition. When self-hosting with sovereignty, stick to fully open-source components unless you have a dedicated support contract.

Part 19: Final MariaDB Migration Governance Checklist

• migration scripts are in version control
• staging import is validated with full application tests
• user accounts and authentication plugins are reconciled
• TLS is enabled for remote connections
• backups are tested with restores
• performance metrics are baseline-recorded
• operational runbook is written and shared locally
• rollback procedures are documented and validated

A successful migration is not just a one-time cutover; it is an operational discipline.

Part 21: Audit, Review, and Ongoing Maintenance

The most resilient MariaDB migration is one you can review after the fact.

21.1 Post-migration audit

After the cutover, run a post-migration audit to compare query plans, connection counts, and lock wait times to the baseline MySQL server.

21.2 Change review process

For any future database change, use a local review process: stage the migration, run the test suite, and update the runbook.

21.3 Dependency matrix

Maintain a matrix of application dependencies, driver versions, and MariaDB compatibility. If a new app version introduces a different connector, validate it before deployment.

Part 22: Coexistence and Polyglot Database Strategies

Some teams keep MySQL and MariaDB side by side during transition.

22.1 Dual-write strategies

Write to both MySQL and MariaDB during the migration window only if you need a rollback path. Evaluate the complexity carefully, since dual-write systems introduce drift risk.

22.2 Read-only shadow replicas

Use MariaDB as a read-only replica to validate queries before cutting over writes. This is a lower-risk way to verify application compatibility.

22.3 Final cutover rules

Stop writes to MySQL, drain connections, verify the latest binlog position, and switch the application to MariaDB.

Part 23: Community and Support

MariaDB has a strong open-source community. Keep local documentation of the versions and packages you rely on.

23.1 Use official MariaDB repos

Pin the repository to mariadb-11.4 and avoid mixing in older community packages.

23.2 Subscribe to update feeds

For self-hosted governance, monitor security advisories from MariaDB and apply updates in a controlled maintenance window.

23.3 Local support documentation

Maintain a local knowledge base with commands, logs, performance knobs, and migration notes. This is the sovereign alternative to relying on external vendor support.

Further Reading

• How to Install MySQL 9 on Ubuntu 24.04 — MySQL baseline for comparison
• MySQL User Management 2026 — user management (identical in MariaDB)
• MySQL Backup Guide 2026 — backup strategies (mysqldump works for both)
• PostgreSQL 17 Performance Tuning — alternative sovereign RDBMS

Tested on: Ubuntu 24.04 LTS (Hetzner CX32). MySQL 8.0.36 → MariaDB 11.4.3. Last verified: May 1, 2026.