Managed MySQL
Last reviewed by Tyler Eastridge
AceMQ runs your MySQL servers for you: monitoring, replication and failover, backups with point-in-time recovery, minor releases and the pager. We work inside your cloud account, data centre or Kubernetes clusters (Tier 3), or on infrastructure AceMQ runs (Tier 4). MySQL 8.0 has been in Oracle Sustaining Support since 21 April 2026, so the move to 8.4 LTS runs as a project inside the service. If Amazon RDS, Aurora or HeatWave suits you better, this page says so.
Support quotes answered within 1 hour, by a senior engineer.
Planning a build, upgrade or migration instead? See AceMQ MySQL consulting and services.
Customers
Partners
What's Included
MySQL services under one contract: incident response, query and index tuning, replication and high availability review, schema changes, and consulting on upgrades and migrations between self-managed and managed MySQL database services.
We manage monitoring of what predicts MySQL incidents: replica lag against your batch window, errant GTIDs, binary log retention and disk, Threads_connected against Threads_running, long transactions and deadlocks. Then we take the pager, so an alert reaches an engineer who knows your topology.
High availability starts with the topology: source and replica topologies, GTID settings, replica parallelism and semi-synchronous options where you use them, with a failover rehearsal on a schedule and a check for errant transactions that would stop a replica starting after promotion. Group Replication and InnoDB Cluster are in scope where you run them.
Full backups with the tool that fits your edition, plus binary logs retained so a restore can stop at a chosen moment. Each is restored into a scratch environment on a schedule and timed against your recovery objectives, because an untested backup is a hope.
Minor releases applied on an agreed cadence after a test on a copy, with rollback steps written down. Major upgrades, such as 5.7 to 8.0 to 8.4 LTS, run as projects inside the service, with authentication and replication checks before the window.
Online DDL checked for the algorithm it will really use before it runs, large changes moved to gh-ost or pt-online-schema-change, slow query log and index review, and buffer pool sizing against the working set.
Accounts, grants and roles reviewed against least privilege, TLS settings checked, and the build you run tracked against Oracle's quarterly security updates. Access to your environment follows your change process and is logged.
Why AceMQ
Run managed MySQL in your own account, data centre or Kubernetes clusters (Tier 3) when residency and compliance keep the data in your boundary, or have AceMQ host it (Tier 4) when you want endpoints and no infrastructure to run. The operator is a MySQL specialist under an AceMQ contract, not a generic hosting provider.
AceMQ holds the contract, the SLA and the escalation path, and brings partner MySQL specialists in as the work needs them. Incidents start with an engineer who has your topology and runbooks in front of them. The 15-minute response is a response time, not a resolution time.
Many MySQL incidents start in what the application does: one huge transaction that serialises replica apply, a pool with no maximum, an ALTER that waits behind a long SELECT. We manage the server and also work on queries, transactions and connection behaviour.
Failover, restore and upgrade runbooks, topology documentation and monitoring configuration are maintained as yours. If you bring operations back in-house, or move a server between your infrastructure and ours, there is a current handover pack.
Cloud, Kubernetes, bare metal, hybrid, and air-gapped — including environments where you can't give us outbound network access.
Managed MySQL compared
People who search for a managed MySQL database are often comparing cloud products. They are platforms: the vendor runs the engine and you work inside its limits. AceMQ's managed service is people, who run MySQL on infrastructure you own or on ours. Each row answers one question.
| Question | AceMQ managed MySQL (Tier 3 or 4) | Amazon RDS for MySQL | Amazon Aurora MySQL | MySQL HeatWave |
|---|---|---|---|---|
| Who runs it | AceMQ engineers with partner MySQL specialists, under a contract with a 15-minute emergency response. | AWS runs the managed instance. You decide when to take a major version upgrade: AWS never makes one automatically. | AWS. A MySQL-compatible engine that reuses MySQL code, with its own version numbers, release cycles and deprecation timelines. | Oracle's managed MySQL service, with analytics, lakehouse, machine learning and generative AI features. |
| Where it runs | Your cloud account, data centre or Kubernetes (Tier 3), or infrastructure AceMQ runs (Tier 4). | AWS. | AWS. | Oracle Cloud Infrastructure, AWS and Azure, each with its own service guide. |
| Which engine and versions | MySQL 8.4 LTS, and 8.0 while you move off it. 9.7 LTS is scoped case by case. | MySQL Community 8.4 and 8.0, with 8.0 under paid Extended Support since 1 August 2026. | Aurora's own version line: check AWS for the dates that apply to yours. | Oracle's MySQL, with HeatWave's added features. |
| Staying on MySQL 8.0 | We can operate it, but Oracle ships no new fixes for it, so the service plans the move to 8.4 LTS. | A fee: Extended Support pricing starts 1 August 2026, steps up on 1 August 2028 and ends 31 July 2029. | Follows Aurora's own timelines, not MySQL's. | Follows Oracle's terms for the service. |
| Best when | You have an existing estate, want data inside your own boundary, run on Kubernetes or on premises, or want one contract across databases and messaging. | You are on AWS and want AWS to run a standard MySQL instance. | You are on AWS and want Aurora's engine and accept that it is not stock MySQL. | You want analytics and machine learning next to your MySQL data in Oracle's service. |
Sources: AWS documentation, MySQL on Amazon RDS versions and Amazon Aurora versions; Oracle MySQL HeatWave User Guide; mysql.com EOL notice; all checked 31 October 2026. Vendor terms change, so check them before you commit.
MySQL 8.0 to 8.4 LTS
Oracle's mysql.com notice says that as of 21 April 2026 MySQL 8.0 is covered under Oracle Sustaining Support and encourages users to move to 8.4 LTS or 9.7 LTS. A managed service has to turn that into a plan.
MySQL 8.4 LTS: Premier Support to April 2029 and Extended Support to April 2032. MySQL 9.7 LTS, released in April 2026: Premier to April 2031 and Extended to April 2034. Oracle's release model gives LTS series five years of Premier and three of Extended Support.
Oracle's release model does not support skipping an LTS series on upgrade, so 5.7 goes through 8.0 and 8.0 goes to 8.4 LTS. From 8.4 the next LTS is 9.7. We plan one hop at a time, each with its own rollback.
8.4 disables the mysql_native_password plugin by default, so older clients and connectors fail at login, not at startup. It also removes binlog_transaction_dependency_tracking and uses writesets only, which changes how a busy replica applies a large transaction. Both are checked before the window.
Inventory of clients and authentication plugins, a rehearsal on a restored copy, replication checks, a rollback plan and a cutover window agreed with you. The old server stays available until the new one has run a full business cycle.
The dates and your options for 5.7 and 8.0 are set out on the MySQL end-of-life article. MySQL end of life: 5.7, 8.0 and 8.4 dates
Tier 3 and Tier 4
Tiers 1 and 2 are AceMQ's MySQL support: you hold the pager and we respond and review. Tiers 3 and 4 are managed services: we hold it. The two managed tiers run the same operations. What differs is where MySQL runs and who owns the infrastructure.
AceMQ operates MySQL in your cloud account, data centre or Kubernetes clusters, with system access and your change process. You keep the account, the data and the infrastructure bill.
AceMQ hosts and operates MySQL on infrastructure it runs, with backups, replication and upgrades included. You get connection endpoints, not a server or an on-call rota.
If you hold MySQL Enterprise Edition, Oracle's support entitlement remains yours and remains the source of Oracle fixes for a supported release. AceMQ operates the servers and prepares the Oracle case with the diagnosis done.
Many estates start with support and a review of replication, backups and the 8.0 position, then hand over operations. Nothing about Tier 3 or 4 requires a big-bang handover.
Tiers 1 and 2 are set out on the MySQL support page. MySQL support: 24/7, 15-minute SLA
Choosing honestly
A managed cloud database is the right answer for some workloads. These are the differences that decide it.
You are on AWS, you run a standard open-source MySQL workload, and you want AWS to run the instance. Plan for the version calendar: 8.0 is now only under paid Extended Support there.
You want Aurora's storage and failover design and accept that it is MySQL-compatible, not MySQL, with its own versions and deprecation dates.
Analytics, a lakehouse or machine learning over the same data matters as much as the transactional side, and you are comfortable inside Oracle's service.
You already run MySQL on virtual machines, on premises or on Kubernetes, need data to stay in your boundary, want to avoid a cloud vendor's version calendar, or want one contract for MySQL, PostgreSQL, Kafka and the rest.
What none of them removes: schema design, query plans and application behaviour still belong to whoever owns the workload.
Price drivers
AceMQ does not publish a price list for managed services. A managed MySQL quote is built from these inputs, and the written quote returns within 1 hour of your request.
How many servers and clusters you run, how large they are, how write-heavy, and which are production.
Single primary, replicas, Group Replication or InnoDB Cluster, and the recovery point and recovery time objectives that set the backup, binary log and failover work.
From business hours to 24/7 on-call with the 15-minute emergency response.
At Tier 3 you pay your provider for infrastructure and AceMQ for operations. At Tier 4 the infrastructure is in the AceMQ quote. A move from 8.0 to 8.4 LTS, if one is due, is scoped in the quote.
Not a fit for
We would rather say so up front.
AceMQ is a specialist service with a contract and senior engineers. If you want a database you provision by clicking, with no contract, buy it from RDS, Aurora or HeatWave.
A migration to PostgreSQL is a separate AceMQ project, scoped on its own, not part of this service. Once the database is on PostgreSQL we can operate it.
Architecture reviews, topology assessments and tuning engagements are consulting, not operations. They sit on the MySQL page and can lead into a managed contract.
A scratch database with no uptime target needs a current version and a backup, not a managed service.
Running several engines? One contract can also cover PostgreSQL, SQL Server and more. Managed PostgreSQL services
Escalation Path
Every tier reaches a senior MySQL engineer. There is no tier-1 triage layer to get through.
P1 escalation path
A replay of one P1, from the first page to the written root-cause analysis
15-minute P1 response, 24/7.
A response time, not a resolution time.
P1 opened, on-call engineer paged
Phone, email or Slack reaches the on-call senior engineer directly, whether the incident is in RabbitMQ, Kafka, Redis, PostgreSQL or Kubernetes. No web form, no tier-1 queue.
Senior engineer on your bridge
A senior engineer who already knows your environment joins a live bridge, so nobody has to re-explain your topology.
Specialists across the stack join
When an incident crosses components, the engineers who know each one join. For RabbitMQ, the path runs to the core team.
Written root-cause analysis
Root cause, the fix applied and the prevention steps, delivered after every P1.
Typical engagements
MySQL support work from AceMQ. Each card links to the full write-up: the database estate, what AceMQ diagnosed or changed, and the result.
Digital Commerce Platform
Emergency remediation of a Memcached tier evicting hot keys while reporting free memory, traced to slab class allocation.
Memcached
Linux
MySQL
KubernetesB2B SaaS Platform Provider
Assessment of Memcached sizing, key distribution, and hit rate to determine whether adding capacity would actually help.
MemcachedLinuxMySQL
TerraformE-Commerce Marketplace Operator
Resolving replica lag that grew to hours during batch windows because single-threaded apply could not keep pace with large multi-row transactions.
MySQLProxySQL
PrometheusLinuxTravel Booking Platform
Ongoing support for deadlocks and lock wait timeouts under booking concurrency, including history list growth from long-running transactions.
MySQLProxySQLPrometheusKubernetesMedia Streaming Provider
Review of replication topology, failover readiness, backup recoverability, and configuration drift across a MySQL estate that had grown organically.
MySQLPercona XtraBackupProxySQLTerraform
Online Travel Platform
Ongoing support for a MySQL change data capture pipeline that needed a full re-snapshot after a planned outage outlasted binlog retention and a trimmed schema history topic.
DebeziumMySQLSQL ServerOracle Database
Kafka
Amazon RDSSupport options
AceMQ offers MySQL support in four tiers, each handing more of the day-to-day work to AceMQ: 24/7 support and incident management for servers your DBAs run, proactive monitoring that finds replica lag, errant GTIDs and backup gaps first, managed MySQL on your own infrastructure, and fully managed MySQL on AceMQ infrastructure. MySQL 5.7 to 8.4 is supported, and 5.7 and 8.0 can be kept patched through OSSeva.
You run it, we back you up
Best for: DBA teams that run MySQL themselves and need senior escalation cover.
You run it, we watch it with you
Best for: Teams that want the stalled replica or the unrestorable backup found in a review, not in an outage.
We run it in your cloud or data centre
Best for: Regulated estates that must keep MySQL inside their own boundary.
We host it and run it, as a service
Best for: Teams that want MySQL without a DBA rota or an Aurora bill they cannot tune.
| Who does what | Tier 1 24/7 support | Tier 2 Proactive monitoring | Tier 3 Managed, your infrastructure | Tier 4 Fully managed by AceMQ |
|---|---|---|---|---|
| Who runs MySQL day to day? | Your team | Your team, with AceMQ reviews | AceMQ | AceMQ |
| Where does it run? | Your infrastructure | Your infrastructure | Your cloud account or data centre | AceMQ infrastructure |
| 24/7 incident response | 15-minute P1 response | 15-minute P1 response | 15-minute P1 response | 15-minute P1 response |
| Health checks and CVE alerts | On request | Scheduled | Included | Included |
| Patching and upgrades | Your team, AceMQ advises | Planned with AceMQ | Done by AceMQ | Done by AceMQ |
| Monitoring and on-call | Your team | Your team | AceMQ | AceMQ |
| Data, keys and accounts | Yours | Yours | Yours | Your data, hosted by AceMQ |
Every Tier can start as an ad hoc engagement or an annual partnership, and you can move up or down a Tier as your team changes.
One partner for MySQL
Support is one part of what AceMQ does for MySQL. The same engineers deliver consulting, health checks, migrations and end-of-life cover, and support the systems that usually run next to it.
Yes. Tier 3 runs in your AWS or Azure account, on virtual machines, on VMware, on Kubernetes you run, or on premises including air-gapped sites, using your access controls and change process. AceMQ works with system access and database administrative access, inside that change process and logged. Tier 4 is the alternative when you would rather run no infrastructure. RDS, Aurora and HeatWave are run by their vendors, so Tiers 3 and 4 do not apply to them; ask us about support for the workload around them.
Oracle moved MySQL 8.0 to Sustaining Support on 21 April 2026, so it ships no new fixes for it. AceMQ can operate 8.0 in the meantime, and plans the move to 8.4 LTS as a project inside the service, one hop at a time with a rollback at each step. Oracle's release model does not support skipping an LTS series, so a 5.7 server goes to 8.0 and then 8.4.
Yes. AceMQ works on MySQL 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 contract that covers 24/7 support and proactive reviews. Many teams start ad hoc and move to an annual contract once the first engagement is done.
Managed MySQL is quoted per scope, with no list price: the price depends on the number of environments and nodes, the SLA, whether AceMQ runs MySQL on your infrastructure (Tier 3) or on ours (Tier 4), and the access and change process you need. Request a quote and AceMQ replies within 1 hour.
Let's talk
Reactive cover, proactive reviews, or AceMQ running MySQL for you on your infrastructure or ours. A senior engineer scopes it with you, and quote requests are answered within 1 hour.
Production incident right now?Email a MySQL Architect
Send us a message and we'll follow up within 1 hour — or book a free 30-min consultation directly.
305-204-2607info@acemq.comPrefer to talk now? Call us directly or use the consultation tab to find a time that works.
