Logo-Icon
HOMEABOUTSERVICESHOW WE WORKBLOGInstagram-Icon Talk To an Expert
RadixTrie-image
MySQL and MariaDB support
Support Models

MySQL and MariaDB Support: Where Small Databases Cause Big Outages

MySQL and MariaDB run websites, integrations, internal tools and more than a few production systems that grew up quietly. What proper support looks like for them, and the failure patterns that recur.
By RadixTrie3 September 20262 min read
MySQL and MariaDB have a habit of becoming critical without anyone deciding they should be. A database set up for a website or an internal tool ends up feeding the CRM, the integration layer and a reporting process the finance team depends on. Because it started small, nobody assigned it a DBA. Then it fails, and the outage is anything but small. This article describes what proper MySQL and MariaDB support looks like and the patterns we see most often.

The failure patterns

  • Backups nobody has restored. A nightly dump exists, sometimes on the same disk as the database, and has never been used to rebuild anything.
  • Replication that quietly broke. A replica stopped applying changes weeks ago; the application reads stale data or the failover target is useless.
  • Default configuration at scale. InnoDB buffer pool sizing, connection limits and logging settings left at installation defaults long after the workload outgrew them.
  • Schema and query debt. Missing indexes, unbounded queries from application frameworks, and tables that were never designed for the volume they now hold.
  • Unsupported versions. MySQL 5.7 reached end of life in October 2023, yet it is still common in production. MariaDB estates often run releases that have also fallen out of their support window; check the vendor lifecycle pages for the exact dates.

What proper support includes

  1. Backups you can restore. Consistent backups with binary log retention for point-in-time recovery, stored away from the server, and restore-tested on a schedule.
  2. Replication and availability that are monitored and exercised. Lag and errors alerted, failover tested, and the topology documented.
  3. Configuration matched to the workload. Memory, I/O and connection settings reviewed against what the system actually does.
  4. Performance tuning as routine. Slow query analysis, indexing and query rewrites handled continuously rather than after complaints.
  5. Upgrades planned and executed. A path off unsupported versions with testing and rollback, and a policy for staying within support thereafter.
  6. Security basics. Least-privilege accounts, encrypted connections, no anonymous or default users, and auditing appropriate to the data.
  7. Someone senior to call. Direct access to an engineer who knows the environment, at the hours the business needs.
Two questions expose most MySQL and MariaDB risk: which version are we on, and when did we last restore a backup? If either answer takes more than a minute to find, you have your starting point.

MySQL or MariaDB: does it matter for support?

They share ancestry and much of their tooling, but they have diverged in features, replication options, storage engines and release cadence. Good support treats them as related but distinct: the right backup method, the right clustering technology and the right upgrade path differ. If your estate has both, a single team that understands both saves a great deal of confusion.

Cloud-managed MySQL still needs a DBA

Managed cloud offerings remove patching and hardware from your plate. They do not tune your queries, design your indexes, size your instance sensibly or test your restores. The judgement work remains, and it is exactly where outages and cost overruns come from.

How RadixTrie supports MySQL and MariaDB

RadixTrie is a South African database specialist with senior engineers across MySQL/MariaDB, Microsoft SQL Server, Oracle and PostgreSQL, with offices in Randpark Ridge and Stellenbosch. The model is direct access to senior database experts, no service desk and no escalation loops, and it covers 24/7 support, managed DBA services, performance tuning, health checks, upgrades and migrations, high availability and disaster recovery, and security and monitoring. See our <a href="/services">services page</a>, or read <a href="/blog/managed-dba-services-explained">how managed DBA services work</a>.
<strong>Related reading:</strong> <a href="/blog/managed-dba-services-explained">Managed DBA Services Explained: What You Hand Over, What You Keep</a> &middot; <a href="/blog/database-performance-tuning">Database Performance Tuning as a Habit, Not a Project</a> &middot; <a href="/blog/high-availability-disaster-recovery">High Availability and Disaster Recovery: Tested Beats Configured</a>
Is a small MySQL database carrying a big part of your business? Let's make sure it holds.
TAGSMySQLMariaDBDatabase SupportManaged DBASouth Africa
RadixTrie-image
MySQL and MariaDB support
Support Models

MySQL and MariaDB Support: Where Small Databases Cause Big Outages

MySQL and MariaDB run websites, integrations, internal tools and more than a few production systems that grew up quietly. What proper support looks like for them, and the failure patterns that recur.
By RadixTrie3 September 20262 min read
MySQL and MariaDB have a habit of becoming critical without anyone deciding they should be. A database set up for a website or an internal tool ends up feeding the CRM, the integration layer and a reporting process the finance team depends on. Because it started small, nobody assigned it a DBA. Then it fails, and the outage is anything but small. This article describes what proper MySQL and MariaDB support looks like and the patterns we see most often.

The failure patterns

  • Backups nobody has restored. A nightly dump exists, sometimes on the same disk as the database, and has never been used to rebuild anything.
  • Replication that quietly broke. A replica stopped applying changes weeks ago; the application reads stale data or the failover target is useless.
  • Default configuration at scale. InnoDB buffer pool sizing, connection limits and logging settings left at installation defaults long after the workload outgrew them.
  • Schema and query debt. Missing indexes, unbounded queries from application frameworks, and tables that were never designed for the volume they now hold.
  • Unsupported versions. MySQL 5.7 reached end of life in October 2023, yet it is still common in production. MariaDB estates often run releases that have also fallen out of their support window; check the vendor lifecycle pages for the exact dates.

What proper support includes

  1. Backups you can restore. Consistent backups with binary log retention for point-in-time recovery, stored away from the server, and restore-tested on a schedule.
  2. Replication and availability that are monitored and exercised. Lag and errors alerted, failover tested, and the topology documented.
  3. Configuration matched to the workload. Memory, I/O and connection settings reviewed against what the system actually does.
  4. Performance tuning as routine. Slow query analysis, indexing and query rewrites handled continuously rather than after complaints.
  5. Upgrades planned and executed. A path off unsupported versions with testing and rollback, and a policy for staying within support thereafter.
  6. Security basics. Least-privilege accounts, encrypted connections, no anonymous or default users, and auditing appropriate to the data.
  7. Someone senior to call. Direct access to an engineer who knows the environment, at the hours the business needs.
Two questions expose most MySQL and MariaDB risk: which version are we on, and when did we last restore a backup? If either answer takes more than a minute to find, you have your starting point.

MySQL or MariaDB: does it matter for support?

They share ancestry and much of their tooling, but they have diverged in features, replication options, storage engines and release cadence. Good support treats them as related but distinct: the right backup method, the right clustering technology and the right upgrade path differ. If your estate has both, a single team that understands both saves a great deal of confusion.

Cloud-managed MySQL still needs a DBA

Managed cloud offerings remove patching and hardware from your plate. They do not tune your queries, design your indexes, size your instance sensibly or test your restores. The judgement work remains, and it is exactly where outages and cost overruns come from.

How RadixTrie supports MySQL and MariaDB

RadixTrie is a South African database specialist with senior engineers across MySQL/MariaDB, Microsoft SQL Server, Oracle and PostgreSQL, with offices in Randpark Ridge and Stellenbosch. The model is direct access to senior database experts, no service desk and no escalation loops, and it covers 24/7 support, managed DBA services, performance tuning, health checks, upgrades and migrations, high availability and disaster recovery, and security and monitoring. See our <a href="/services">services page</a>, or read <a href="/blog/managed-dba-services-explained">how managed DBA services work</a>.
<strong>Related reading:</strong> <a href="/blog/managed-dba-services-explained">Managed DBA Services Explained: What You Hand Over, What You Keep</a> &middot; <a href="/blog/database-performance-tuning">Database Performance Tuning as a Habit, Not a Project</a> &middot; <a href="/blog/high-availability-disaster-recovery">High Availability and Disaster Recovery: Tested Beats Configured</a>
Is a small MySQL database carrying a big part of your business? Let's make sure it holds.
TAGSMySQLMariaDBDatabase SupportManaged DBASouth Africa