Support Models
MySQL and MariaDB: Where Small Databases Cause Big Outages
MySQL and MariaDB run websites, integrations and internal tools that quietly became critical. The failure patterns that recur, and the realistic options once you find them in an estate.
Need a hand with this? Talk to a senior database DBA ↓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 reporting pack and a customer-facing integration, while still being run the way it was on day one. Nobody owns it, nobody has restored it, and it does not appear on any architecture diagram. This is what that looks like when it goes wrong, and what to do about it.
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 maintenance.
What proper support includes
- 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.
- Replication and availability that are monitored and exercised. Lag and errors alerted, failover tested, and the topology documented.
- Configuration matched to the workload. Memory, I/O and connection settings reviewed against what the system actually does.
- Performance tuning as routine. Slow query analysis, indexing and query rewrites handled continuously rather than after complaints.
- Upgrades planned and executed. A path off unsupported versions with testing and rollback, and a policy for staying within support thereafter.
- Security basics. Least-privilege accounts, encrypted connections, no anonymous or default users, and auditing appropriate to the data.
- 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 found the problem.
MySQL or MariaDB: does it matter?
They share ancestry and much of their tooling, but they have diverged in features, replication options, storage engines and release cadence. Treat them as related but separate products. Assuming a MariaDB estate behaves like MySQL, or that a tool proven on one is safe on the other, is how upgrade windows overrun.
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 bill also makes inefficiency expensive in a way an owned server never did: a badly indexed query does not get faster in the cloud, it gets metered.
Where RadixTrie fits
RadixTrie is a South African database specialist with senior engineers and offices in Randpark Ridge and Stellenbosch. The platforms we lead with are Microsoft SQL Server, Oracle and PostgreSQL. MySQL and MariaDB are not on that list, but we do take the work when it comes to us, and we resource it deliberately rather than stretching an engineer across a platform they only half know.
We still look at them, for one practical reason: most estates are mixed, and a risk nobody has examined is still a risk. A database health check covers what is actually running, including the MySQL instance that never made it onto the diagram, and ends in a prioritised list rather than a sales pitch. Where the sensible answer is to consolidate a small MySQL workload onto a platform you already run, that is a migration we plan and execute. Where it is not, we will say so. If MySQL or MariaDB is the only database you run, tell us what you have and we will be straight with you about how we would cover it.
Need a hand with this?
Tell us what you run today and when it has to move. A senior database DBA will reply directly, usually within one working day. Prefer email or phone? Write to expert@radixtrie.com or call +27 10 143 0304, or use the contact page to book a 30-minute call.
TAGSMySQLMariaDBDatabase Health CheckMigrationSouth Africa