MySQL database engineering
Almost nobody chooses MySQL today. They inherit it. The real questions are whether the schema still fits the product, whether the upgrade is overdue, and whether moving off it is worth the disruption.
01Capabilities
The work an inherited MySQL database actually needs
This page is about an existing MySQL estate and what to do with it. If you are choosing a database for a system that does not exist yet, read our PostgreSQL page instead, because that is the decision it covers. Four shapes of MySQL work come up repeatedly.
- Schema
Transactional application databases
The data layer under a working product: users, orders, documents, billing records. Schema design, constraints, and the transaction boundaries that decide whether a half-finished operation leaves money recorded in two places at once. In regulated settings such as healthcare software, encryption at rest and a usable audit trail are part of the schema decision rather than something added later.
- Performance
Schema and query work on a live system
When an application gets slow, the cause is usually a query shape, a missing composite index, or a table that has quietly grown past what its access pattern assumed. A bigger instance hides that for a quarter and then stops working. We treat it as a design problem with a measurable target, which is part of what our data engineering practice does.
- Upgrades
Version currency and upgrades
MySQL 5.7 is out of support and a lot of production data still sits on it. The upgrade is mostly about character sets, stricter SQL modes, and statements the optimiser now plans differently. That is testable work rather than a leap of faith, but it needs a rehearsal against a copy of your real data.
- Recovery
Replication, backup, and a restore you have actually run
Read replicas, failover behaviour, and more importantly a restore that somebody has performed end to end with a stopwatch. A backup nobody has restored is a hope with a cron entry, and it is the most common gap we find on an inherited estate.
02Case studies
Products running on MySQL today
Three systems in production, across SaaS, healthcare and fintech.
See all case studies
SaaSWaiverKing: Software Development for Waiver Form CreatorWaiverKing is a document management business serving primarily the health and fitness industries. The platform is partnered with MindBody Online, one of the largest business-systems providers for gyms and yoga studios.Weeks to hoursTime for an update to reach live
HealthcareCancerDocs: HIPAA compliant Healthcare Software DevelopmentDevelopment in accordance with HIPAA Security Rules within a medical project.
FintechAccounting Software Integration & Automation for a Financial Advisory CompanyBookkeeping reconciliation automated on a build unicrew took over, with no issues reported as transaction sizes grew in testing.
03Fit
Invest in it, or move off it
MySQL is rarely the interesting decision. It is usually already there, running the business, and the real question is whether to invest in it or keep it as it is. Each row is the call we would make on the database you have, and three of them link to the page that covers it. Nothing we earn depends on which database you run.
| Your situation | What we recommend |
|---|---|
| An existing MySQL system on a supported version, carrying an ordinary transactional workload | Stay on MySQLSpend the budget on schema, indexes and the restore drill: on a healthy system, that is where the gains are. |
| A new system, with no MySQL legacy to respect | Different pageOur PostgreSQL page. Richer types, stricter default behaviour, and stronger handling of complex queries. |
| Genuine engine limits: window-heavy reporting, JSON as a first-class citizen, complex analytical queries | Usually PostgreSQLOccasionally not a relational database at all. Confirm the limit is the engine and not the query before funding a move. |
| A Microsoft estate: .NET services, Active Directory, SQL Server licences you already pay for | Different pageOur SQL Server page. Tooling and identity integration outweigh any per-engine feature comparison. |
| Reporting is what actually hurts, and it is competing with transactional traffic | Offload the reportingMove analytics off the application database: a read replica first, and a warehouse only if the questions justify one. |
| Self-managed MySQL on a virtual machine, a small team, and nobody genuinely on call | Managed MySQLTake it from your cloud provider. Patching, backups and failover stop being one person's memory, which is worth more than the hosting saving. |
Scope
What we own on MySQL work is the data model and its consequences. That means whether the constraints actually prevent bad states, whether the query plans hold as tables grow, and whether your team can restore the database under pressure. We do this under an ISO 27001:2022 certified information-security management system. unicrew has been building on this stack since 2012, with 100+ senior in-house engineers across six countries. Where a week of index work does the job, that is the work we scope, ahead of any migration.
04Delivery
The order that keeps a live database safe while we learn it
Most of this work is inherited rather than greenfield. The first two steps are where it is won, and we do not skip them to look fast.
- Read the schema and the real query trafficTable definitions, the foreign keys that exist only in application code, and the slow query log from production. The schema tells you what was intended; the query log tells you what the application actually does. On any system old enough to matter, those two have diverged.
- Establish the recovery positionWhat the backups contain, how old the newest usable one is, and how long a full restore takes when somebody times it. We do this before changing anything, because every later decision depends on how much room you have to be wrong.
- Fix the cheap things and measure the resultIndexes, query shapes, connection handling, and getting reporting queries off the primary. This is where most performance complaints actually live, and it is reversible work with a number attached to it. Every migration goes through the same QA and test automation practice as our own builds.
- Then decide about version, topology or engineUpgrade, add replicas, or move to another engine, decided once the system is understood and stable rather than in the first week. Sequencing it this way means a regression has one plausible cause instead of five.
05Stack
What surrounds a MySQL database in practice
The technologies that turn up around the same systems, each with its own page if that is the decision you are actually making.
06Questions
Upgrades, performance, and the migration question
The questions an inherited database raises, answered as an engineer would.
Yes, and on database work that often makes sense, because your people hold context we would otherwise reconstruct. Our engineers own the data model with you, because a schema decision is the hardest thing here to reverse. An architect outside the delivery team reviews the design, and migrations go through the same QA practice as our own work. Team extension is managed teams; an outcome is data engineering.
For a system that already runs on MySQL and works, MySQL. The migration cost is real and the benefit is often theoretical. For a new system with no legacy to respect, PostgreSQL: richer types, stricter defaults, and stronger handling of complex queries. The bad version of this decision is migrating a healthy database to fix what turns out to be three missing indexes.
Usually yes, and that is where we would start. Indexes, query shapes, connection pooling, schema changes on hot tables, and moving reporting traffic off the primary account for most of what gets called MySQL being slow. We agree a target and a measurement method first, so the work can be judged. If the engine really is the limit, you then have evidence instead of a hunch.
It is out of support, which makes it a security position as much as a technical one. The upgrade itself is more tedious than dangerous: character set and collation changes, stricter SQL modes, and an optimiser that plans some queries differently. All of that is discoverable by rehearsing against a copy of production data, which is how we would run it rather than upgrading and watching.
A scoping call with an engineer rather than a salesperson. For an existing database we ask for the schema and a slow query log beforehand, because an hour reading real query traffic beats three hours of description. What comes back is written: what we would change first, what we would keep, and where the recovery risk sits. Most engagements start within two to four weeks.
Three shapes, and which fits depends on how settled the scope is. Time and materials is billed hourly and quoted per project, which suits work still moving. Fixed price is outcome based, and we only offer it once the first read is done. Team extension is billed monthly per engineer. The rate depends on the seniority mix, so it is quoted rather than listed.
Inherited a MySQL database nobody wants to touch?
Send us the schema, the slow query log, and whatever you know about the backups. You will get an engineer's read on what to fix first. That includes where the database is best kept exactly as it is.