---
title: "MySQL | Skills We Assign For | Azendo"
description: "MySQL in existing estates — replication, schema change at volume, and the Azendo roles assigned for database work."
url: "https://azendo.co/skills/mysql/"
---

[Skills](https://azendo.co/skills/) Data stores and query 

# MySQL.

MySQL is a widely deployed open-source relational database, common in web applications and in estates built before PostgreSQL became a default. Most commercial MySQL work is operating and evolving an existing installation rather than choosing it for something new.

## Where MySQL fits on a long engagement.

A long-running MySQL installation accumulates decisions: a replication topology someone set up years ago, a schema with columns nobody can explain, and a backup process whose restore path has never been tested. Establishing which of those is actually a risk is usually the first useful week of work.

Schema change is where MySQL estates hurt. Altering a large table can lock it, which on a live system means either a maintenance window or an online-change tool and a rehearsal. Teams that have not done it before tend to underestimate it exactly once.

## What an assigned team does with MySQL.

Inherited MySQL is a knowledge problem more than a technical one. The topology, the failover behaviour and the reason a particular table has no foreign keys are all undocumented, and reconstructing that takes weeks the first time and zero the second — which only happens if the same person is still there.

The first work worth doing is almost never a feature. Proving a restore, understanding the replication lag and finding the queries that will fail at twice the volume are what protect everything assigned after them, and they sit under [DevOps managed services](https://azendo.co/services/cloud-and-devops/) as often as under data work.

## What we use MySQL for.

* Testing the restore, not the backup Proving the recovery path works, which is a different exercise from confirming a backup file exists.
* Schema change without downtime Large table migrations planned and rehearsed rather than attempted during a release window.
* Read scaling Replicas and routing introduced deliberately, with the application aware of replication lag rather than surprised by it.

## How MySQL capacity is assigned.

MySQL work is assigned under [managed data services](https://azendo.co/services/data-engineering/) where the database is the constraint, or alongside backend capacity where the application is.

## Roles we assign MySQL for

* [Database Administrator Data engineering](https://azendo.co/services/data-engineering/database-administrator/)
* [Backend Developer Software development](https://azendo.co/services/software-development/backend-developer/)

## Service lines it sits in

* [Data engineering](https://azendo.co/services/data-engineering/)
* [Software development](https://azendo.co/services/software-development/)

Capacity is agreed as a committed monthly capacity across a discipline, not per skill.

## Related in data stores and query

* [SQL — skill we assign for](https://azendo.co/skills/sql/)
* [PostgreSQL — skill we assign for](https://azendo.co/skills/postgresql/)
* [MongoDB — skill we assign for](https://azendo.co/skills/mongodb/)
* [Snowflake — skill we assign for](https://azendo.co/skills/snowflake/)
* [BigQuery — skill we assign for](https://azendo.co/skills/bigquery/)
* [Redis — skill we assign for](https://azendo.co/skills/redis/)
* [Prisma — skill we assign for](https://azendo.co/skills/prisma/)
* [Postgres — skill we assign for](https://azendo.co/skills/postgres/)

## Tell us what your roadmap needs MySQL for.

A service delivery manager replies with the disciplines we would assign, the monthly capacity and what the first month looks like.

[All skills we assign for](https://azendo.co/skills/)