24/7 MariaDB Support with a 15-Minute Emergency SLA

MariaDB support covers 24/7 emergency incident response with a 15-minute SLA, root cause analysis on every P1, Galera Cluster and replication review, MaxScale configuration, query and InnoDB tuning, CVE and patch advisory, quarterly health checks, and upgrade or migration support. Every ticket goes to a named senior engineer assigned to your account. There is no tier-1 triage layer and no per-incident charge.

P1 emergencies, such as a Galera cluster without quorum, a primary down, replication broken or a full disk, get a 15-minute first response with a senior engineer joining a live bridge. P2 critical issues are 1 hour, P3 high-priority 4 hours, and P4 standard questions next business day. These are contractual response times covering nights, weekends and holidays.

The two share history and a wire protocol, but they have diverged far enough that MySQL runbooks mislead. MariaDB GTIDs use a domain-server-sequence format that is not compatible with MySQL's UUID-based GTIDs. Galera Cluster ships with MariaDB, so synchronous multi-primary replication, quorum and state transfer are everyday concerns. MaxScale is MariaDB's own proxy for read/write splitting and failover. MariaDB carries storage engines MySQL does not, including Aria, MyRocks, ColumnStore and Spider. JSON is an alias for LONGTEXT with a JSON_VALID check rather than a binary type, which matters for dumps and replication from MySQL. And from 11.0 the optimizer uses a different cost model. Our engineers support both, which is why we keep the advice separate.

All of them in production use, from 10.4 through the 13.x rolling releases. According to the MariaDB Foundation's maintenance policy, the current LTS lines are 10.11 (community end of life 16 February 2028), 11.4 (29 May 2029), 11.8 (4 June 2028) and 12.3 (12 June 2029). Rolling releases are maintained only until the next one replaces them: 13.0 to the fourth quarter of 2026 and 13.1 to the first quarter of 2027. MariaDB 10.6 reached community end of life on 6 July 2026, 10.5 on 24 June 2025 and 10.4 on 18 June 2024.

Yes. We support 10.6, 10.5, 10.4 and older releases that no longer receive community fixes, because plenty of regulated and vendor-certified environments cannot upgrade on the Foundation's calendar. For security patches, AceMQ's OSSeva platform provides patched builds of MariaDB 10.4, 10.5 and 10.6 after community maintenance ends, in the same series and with the same data directory, so applying one is a normal minor update. In parallel we plan the move to a current LTS, usually 11.8 or 12.3, so the freeze has an end date.

Yes, and these are among the most common MariaDB calls we take. After a partition, only the side holding quorum stays Primary; the rest refuse writes to protect consistency. Recovery means finding the node with the highest committed seqno, bootstrapping from it and letting the others rejoin, without bootstrapping two sides and creating diverged data. A node that will not rejoin is usually failing SST because of credentials, firewall ports or disk space, or falling back to a full SST because the donor's gcache is too small for IST. We fix the incident first, then the node count, arbitrator and gcache sizing that caused it.

Three things catch most teams. The optimizer cost model introduced in 11.0 changes some query plans, so a small number of queries get slower and need index or statistics work. The InnoDB change buffer was removed in 11.0, and its settings no longer apply. And from 11.4, SSL is enabled on the server by default, clients require it and verify the server certificate, and replication does the same, so old client libraries and connection strings can fail at connect time. We rehearse the upgrade on a restored copy, run mariadb-upgrade, and on Galera roll it node by node, waiting for each node to resync before the next.

MariaDB enterprise support is sold through mariadb.com with MariaDB Enterprise Server, and it is the source of enterprise builds and of maintenance beyond the community end-of-life dates for that product. It is worth keeping if you depend on enterprise-only builds or tooling. AceMQ supports the MariaDB you actually run, including Community Server, versions past community end of life, Amazon RDS for MariaDB, and the MySQL, PostgreSQL and other systems around it, under one contract with a 15-minute emergency SLA. Where a fault is a genuine product defect on Enterprise Server, we prepare the vendor case with the diagnosis done.

Yes, in either direction. From MySQL 5.7 and earlier, the MariaDB Foundation states that mariadb-upgrade can upgrade the data files in place. MySQL 8.0 and later use a different data dictionary, so moving from 8.0 to MariaDB is a logical dump and load with compatibility testing for JSON columns, authentication plugins, collations and replication. We assess the application first, then run the migration with a rehearsed cutover and rollback.

Yes. AceMQ works on MariaDB in two ways: ad hoc engagements for a defined piece of work, such as a health check, an upgrade or an incident, or an annual partner engagement that covers 24/7 support, proactive reviews and named engineers. Many teams start ad hoc and move to an annual partnership once the first engagement is done.

Every AceMQ proposal is tailored to your requirements: your MariaDB environment, the SLA you need, the hours of cover and the scope of work. Most contracts run $24,000–72,000 a year, depending on the SLA, the scope and how MariaDB is deployed, with aggressive discounts when several technologies share one contract. Request a quote and AceMQ replies within 1 hour.