Hire MySQL developers

MySQL sits under an enormous share of the web, and hiring for it means finding someone who understands its storage engine and replication rather than only its syntax.

What MySQL actually is

MySQL is an open-source relational database owned by Oracle, with MariaDB as a widely used community fork. It is the default database behind WordPress, most PHP applications, a great deal of commerce, and a very large number of business systems. Its installed base is enormous and much of it is older than the people now maintaining it.

Its historical reputation for being fast but loose is largely out of date. Modern versions have proper transactional behaviour through the InnoDB storage engine, reasonable standards compliance, and features such as window functions and common table expressions that were once reasons to prefer PostgreSQL. Many criticisms still repeated describe a version nobody should be running.

The genuinely important technical facts for hiring are about the storage engine and about defaults. Whether a table uses InnoDB or the older MyISAM determines whether it has transactions and row-level locking at all. Character set and collation defaults have historically caused real data problems. Replication configuration determines what happens when the primary fails. These are the things that distinguish someone who has operated MySQL from someone who has queried it.

The part that separates seniors from mid-levels

The storage engine is the first thing to understand. InnoDB provides transactions, row-level locking, foreign keys and crash recovery; MyISAM provides none of those and locks whole tables. Any table still on MyISAM in a system with concurrent writes is a bottleneck and a data-integrity risk. A developer who checks the engine before diagnosing a locking problem is telling you they have done this before.

Indexing has a MySQL-specific dimension that catches people out. InnoDB organises rows physically by the primary key, so the choice of primary key affects how every secondary index performs: secondary indexes store the primary key and require a second lookup. A large or random primary key therefore makes every index bigger and less efficient. This is why the advice to use a compact sequential primary key is more consequential here than in some other databases.

Replication is the third and it is where operational experience shows. Asynchronous replication means replicas can lag, so an application that writes to the primary and immediately reads from a replica can fail to see its own write. That is a subtle bug class that appears under load and confuses everyone. Understanding lag, knowing how failover works, and knowing what is lost when it happens are what separate operators from users.

Where MySQL is used

The label “MySQL developer” covers several jobs that share a technology and little else. These are the settings the work usually turns up in, and the one you are hiring into should shape the whole process, because the judgement each demands is different.

Web applications

The default database for PHP, WordPress and a very large share of the web.

E-commerce

Behind WooCommerce, Magento and many custom stores, where order integrity matters.

Software as a service

Multi-tenant applications, often with database-per-tenant or shared-schema designs.

Legacy business systems

Long-lived internal applications, frequently on old versions with old defaults.

Analytics on operational data

Reporting run against production databases, usually until it causes a problem.

Migration work

Version upgrades and moves between MySQL, MariaDB and PostgreSQL, all common.

If a candidate's experience sits in a different row of that list from the work you have, that is not a reason to reject them, but it is the thing to probe. Ask what would be different about their approach in your setting. Someone who can answer that has transferable judgement. Someone who says it would be much the same has probably not thought about it.

Which MySQL versions are still supported

MySQL publishes support windows per release series, and because older versions carry defaults that permit silent data truncation, the version a system runs is a data-integrity fact rather than a preference.

The table is generated from public release data rather than written by hand, so it states what is supported today rather than what was true when any given article was published. Of the 8 most recent release lines, 1 are still maintained and 7 have passed their published end-of-life date. That distinction is the practical one when you read a job specification: a requirement written against a line that is now out of support tells you the specification is older than the codebase it describes, and it is worth asking which of the two the new developer will actually work in.

Source: endoflife.date public release data, read 2026-09-25.

Two questions follow from this table in an interview. The first is which line the candidate has most recently shipped against, because someone whose last production work was on an unsupported line has not had to deal with the changes since. The second is how they have handled an upgrade. Version migrations are where you see whether a developer reads release notes, writes characterisation tests before changing anything, and knows how to stage a rollout, or whether they upgrade in place on a Friday and hope.

The toolchain around it

Nobody hires for MySQL alone. The surrounding tools are where most of the day-to-day work happens, and a gap in any of them costs more time than a gap in the core library. This is the set that turns up most often on real job specifications alongside it.

InnoDB

The storage engine that provides transactions and row-level locking. The presence of MyISAM is a finding.

EXPLAIN and the slow query log

The primary diagnostic tools, and the thing to interview about.

Replication

Read replicas and failover. Lag is the operational concern.

ProxySQL or a connection pooler

Connection management and read routing at scale.

Percona Toolkit

Online schema changes and diagnostics, widely used on busy systems.

A managed service

RDS, Aurora, Cloud SQL or equivalent, which is how most new deployments run.

Backup with tested restore

Logical or physical backups, with a restore somebody has actually performed.

Monitoring

Slow queries, replication lag, connection counts and buffer pool behaviour.

Related skills that frequently appear on the same specification: PHP, Laravel, WordPress, SQL, WooCommerce.

What to test in an interview

These are the topics that separate candidates in practice. Each one is given with why it discriminates, what a strong answer sounds like, and the response that should make you slow down. None of them requires a whiteboard.

Storage engines

Determines whether a table has transactions at all, and MyISAM is still out there.

• Strong answer: Knows the difference, checks the engine when diagnosing locking, and has converted tables.
• Warning sign: Unaware that more than one engine exists.

Reading a query plan

The core diagnostic skill, and frequently absent.

• Strong answer: Reads EXPLAIN output, recognises a full table scan, and understands when an index is not being used.
• Warning sign: Has never run EXPLAIN.

Primary key choice and index structure

A MySQL-specific consequence that affects every index in the table.

• Strong answer: Explains clustered index behaviour, prefers compact sequential keys, and knows why a random key hurts.
• Warning sign: Treats primary key choice as arbitrary.

Replication lag

Produces subtle bugs that only appear under load.

• Strong answer: Knows replicas can lag, routes reads accordingly, and has diagnosed a read-after-write problem.
• Warning sign: Assumes a replica is immediately consistent with the primary.

Schema changes on large tables

Where MySQL causes outages.

• Strong answer: Knows which operations lock, uses online schema change tooling, and tests against production-scale data.
• Warning sign: Runs an ALTER on a large table during business hours.

Character sets and collation

A historical MySQL trap that still bites, particularly with emoji and multilingual data.

• Strong answer: Uses full Unicode support, knows the difference between the older and newer character sets, and has fixed an encoding problem.
• Warning sign: Has encountered mangled characters and worked around it in the application.

Backup and restore

The difference between a backup and a tested backup.

• Strong answer: Has performed a restore, knows how long it takes, and understands what a point-in-time recovery requires.
• Warning sign: Backups are configured and have never been restored.

Warning signs in a MySQL codebase

The fastest way to read a candidate is to ask what they have found wrong in code they inherited. These are the patterns that come up most often, what they cost, and what fixing them looks like. A developer who recognises three or four of these from their own experience is worth more than one who can recite the documentation.

MyISAM tables in a transactional system

• What you see: Tables still on the older engine, usually inherited.
• What it costs: No transactions, table-level locking under concurrent writes, and no crash recovery.
• The fix: Convert to InnoDB, testing behaviour first since locking and full-text search differ.

Large or random primary keys

• What you see: A wide natural key or a random identifier as the primary key.
• What it costs: Every secondary index carries it, so indexes are larger and less efficient across the whole table.
• The fix: Use a compact sequential primary key and put the natural key in a unique index.

Reading from a replica immediately after writing

• What you see: An application writing to the primary and reading from a replica in the same request.
• What it costs: Users not seeing their own changes, intermittently and under load only.
• The fix: Route reads that must see recent writes to the primary, or wait for the replica to catch up deliberately.

Blocking schema changes

• What you see: An ALTER on a large table run directly.
• What it costs: A table lock and an outage during what was expected to be routine.
• The fix: Use online schema change tooling or the database's own online operations, and test against production-scale data first.

Legacy character sets

• What you see: Tables using the older three-byte encoding.
• What it costs: Emoji and some characters cannot be stored, producing corrupted data that is discovered much later.
• The fix: Convert to full Unicode support. Plan it carefully, because index length limits can change.

Reporting against the production primary

• What you see: Heavy analytical queries run on the database serving the application.
• What it costs: Application latency spikes at reporting time, and lock contention affecting users.
• The fix: Route reporting to a replica, or to a separate analytical store.

What each level can own

Job titles are not comparable between companies, so it is more useful to describe levels by what a person can be left to own without supervision. These are the boundaries we use when we assess a MySQL developer.

Junior

Writes queries against an existing schema. Needs review on indexing and on anything inside a transaction.

Mid-level

Owns the schema and queries for an application area, reads plans, and writes migrations safe at real data volumes.

Senior

Owns schema design, indexing strategy, replication topology and performance under load. Can run a version upgrade.

Staff

Owns the database estate, the backup and recovery strategy, sharding or partitioning at scale, and the engine choice itself.

How the work is usually scoped

Team shape follows the kind of work, not the headcount you happen to have budget for. These are the shapes that come up most often and the constraint that actually governs each one.

Performance remediation

• Usual team: One senior engineer, time-boxed.
• What governs it: Slow query log and a few indexes account for most of it. Usually high return.

Version upgrade

• Usual team: One engineer.
• What governs it: Scoped by how far behind and by whether deprecated behaviour is relied upon. Older versions have real defaults problems.

Replication setup or repair

• Usual team: One senior engineer.
• What governs it: Straightforward to set up and requires real care around failover and what is lost.

Migration to PostgreSQL

• Usual team: One to two engineers.
• What governs it: Scoped by how much logic lives in stored procedures and engine-specific behaviour.

Character set conversion

• Usual team: One engineer.
• What governs it: Fiddly on large tables with long indexes. Worth doing properly once rather than working around forever.

Migration work you may actually be hiring for

A large share of MySQL work is not new development. It is moving an existing system from one state to another while it stays in service. These are the migrations that come up most often, and each one asks for a different kind of experience from the person you hire.

MyISAM to InnoDB

• Why teams do it: Transactions, row-level locking and crash recovery.
• What to watch: Locking behaviour and full-text search differ, so test rather than assuming a drop-in conversion. On large tables do it during a quiet period with the table copied rather than altered in place.

An unsupported MySQL version to a supported one

• Why teams do it: Security patches and saner defaults, particularly around strict mode and character sets.
• What to watch: Defaults changes are where applications break, not the upgrade itself. Test with strict mode enabled before switching, because queries that silently truncated data will now fail.

Legacy three-byte character sets to full Unicode

• Why teams do it: Storing emoji and the full range of characters without corruption.
• What to watch: Index length limits change, so some indexes may need shortening or restructuring. Convert on a copy first and check every index survives.

MySQL to PostgreSQL

• Why teams do it: A richer feature set and stronger standards compliance.
• What to watch: Scoped by how much logic lives in stored procedures and engine-specific behaviour rather than by data volume. For a working system without a specific need, the case is often weaker than it looks.

Migration work rewards a different temperament from greenfield work. The useful question in an interview is not whether someone has done the specific migration you face, but whether they have ever run one incrementally: behind a flag, with both paths live, and with a way back. Developers who have only done big-bang cutovers tend to propose them again.

What a good brief for this role contains

Most of the time lost in hiring a MySQL developer is lost before anyone is interviewed, in the gap between what the brief says and what the team actually needs. These are the points that, for this technology specifically, change who the right candidate is. A brief that answers them can be matched in days. One that does not produces a shortlist that looks reasonable and converts badly.

• Which MySQL or MariaDB version, and whether it remains supported.
• Whether any tables still use MyISAM, which changes the integrity picture.
• What the largest tables are, since this determines whether schema changes are routine or hazardous.
• Whether replication is in use and whether the application reads from replicas.
• Whether reporting runs against the production database.
• Whether backups exist and whether anyone has performed a restore.

If you cannot answer some of these yet, that is normal and it is still worth writing down which ones are open. An unknown that is named can be worked around. An unknown that is papered over in a job specification turns into a rejected shortlist and a restart four weeks later.

What the US market pays for this work

MySQL work is counted by the US Bureau of Labor Statistics under Database Administrators. That classification is broader than the technology itself, so treat the figures as the shape of the market a MySQL developer is hired into rather than as a rate card for the skill. Across the United States the Bureau counts 69,990 people in this occupation, with a median annual wage of $104,620.

The spread matters more than the midpoint. The 90th percentile is about 2.7 times the 10th, which is a wide band for a single occupation and tells you that the title on its own carries very little pricing information. Two people described as a MySQL developer can sit at $60,230 and $163,320 in the same national dataset. When a budget is set from a median without asking which end of that range the work actually needs, the hire that follows is usually the wrong one in one direction or the other.

Related classifications are worth reading alongside it, because teams hiring for MySQL frequently end up recruiting against these titles too:

Source: BLS Occupational Employment and Wage Statistics, May 2025. Figures cover all US employers and are not FuturByte rates.

These are employer-side wage figures for people on a US payroll. They exclude employer taxes, benefits, recruitment cost and the months a seat sits empty, all of which are real and none of which appear in a salary line. The useful way to read the table is as the cost of the alternative you are comparing against, not as a number to match.

How US metro markets compare for this role

The same job is priced very differently across the country. Ranked by median annual wage for Database Administrators, the gap between the highest and lowest of the 27 metro areas covered here is a factor of about 1.4. San Jose sits at the top with a median of $138,620; Minneapolis-St. Paul sits at the bottom with $101,610. A budget built from a national median will be wrong in both of those markets, in opposite directions.

Location quotient compares how concentrated this occupation is in the metro against the national average. A value above 1 means the metro has more of this work than its size would predict.

The location quotient column is the more useful one for hiring. A high median tells you what a role costs; a high quotient tells you whether the people exist. Boston, Austin, Baltimore, Raleigh, Washington, D.C. each have a quotient of 1.5 or above, meaning the work is concentrated there well beyond what the size of the local economy would predict. Those are the markets where a search is likely to be quick and competitive at the same time, and where a counter-offer is most likely to take a candidate off the table late in the process.

The opposite case is worth planning for too. In a metro with a low quotient, the total pool is small even when wages look reasonable, so the realistic options are to widen the search radius, accept a longer time to hire, or bring the capability in from outside the local market entirely. That last option is what most teams are weighing when they come to us.

Hiring risks worth naming

Every one of these has produced a bad hire somewhere. They are written down so that the process tests for them deliberately rather than discovering them in month three.

Application developer presented as a database engineer. Writing queries and operating a database are different jobs. Ask about replication and backups.

No experience at real data volume. Everything works with small tables. Ask about the largest table they have altered.

Outdated assumptions about MySQL. Some criticisms describe versions from years ago. Equally, some estates really are still running them.

No restore experience. A backup nobody has restored is a hypothesis. Ask directly whether they have performed one.

Hiring MySQL developers by metro area

Wages for this occupation vary more between US metro areas than most budget models assume. Each page below sets out the published employment and wage figures for that market, how it compares with the national picture, and what the local industry mix means for the kind of MySQL developer who will be available.

• New York, NY $121,550 median
• Seattle, WA $133,180 median
• San Jose, CA $138,620 median
• Washington, D.C. $108,750 median
• San Francisco, CA $127,760 median
• Dallas-Fort Worth, TX $122,390 median
• Los Angeles, CA $112,540 median
• Boston, MA $132,370 median
• Chicago, IL $109,680 median
• Atlanta, GA $110,950 median
• Austin, TX $123,830 median
• Phoenix, AZ $104,280 median
• Philadelphia, PA $104,930 median
• Minneapolis-St. Paul, MN $101,610 median
• Denver, CO $120,120 median
• Detroit, MI $110,160 median
• Houston, TX $116,030 median
• Charlotte, NC $113,890 median
• San Diego, CA $106,820 median
• Salt Lake City, UT
• Miami, FL $105,590 median
• Portland, OR $103,110 median
• Baltimore, MD $123,730 median
• Tampa, FL $124,560 median
• Orlando, FL $115,100 median
• Raleigh, NC $122,950 median
• Kansas City, MO $103,640 median
• Pittsburgh, PA $102,070 median

Frequently asked questions

MySQL or PostgreSQL?

PostgreSQL for new work in most cases, for its richer feature set and stronger standards compliance. MySQL where you are already there, or where the surrounding ecosystem assumes it, which for WordPress, WooCommerce and Magento it does. Modern MySQL is a capable database and the reasons to migrate an existing working system are usually weaker than they first appear.

Should we use MySQL or MariaDB?

Both are actively maintained and largely compatible for ordinary use, though they have diverged over time in features and some internals. MariaDB is the community fork with fully open governance; MySQL is Oracle's. For most applications either works, and the decision usually follows what your hosting or managed service offers.

Why is our MySQL database slow?

Almost always queries without suitable indexes, and the slow query log will tell you which within an hour of being enabled. After that, the usual causes are reporting queries competing with application traffic, and an undersized buffer pool so data is read from disk rather than memory. All three are ordinary to diagnose and fix.

Do we still need to worry about MyISAM?

Only if you have it, and a surprising number of older systems do. Tables on MyISAM have no transactions, lock at table level under concurrent writes, and do not recover cleanly from a crash. Checking which engine your tables use is a two-minute task and occasionally an uncomfortable discovery.

How do we change a large table without downtime?

Use online schema change tooling, or the database's own online DDL where the operation supports it. The mechanism creates a copy, keeps it in step, and switches over. The important part is testing against production-scale data, because an operation that takes a second on a development database can take hours and hold a lock throughout.

Why do users sometimes not see their own changes?

Classic replication lag. The write went to the primary and the subsequent read went to a replica that had not caught up. It appears intermittently and under load, which makes it maddening to reproduce. The fix is to route reads that must reflect a recent write to the primary.

Is it safe to run reports against our production database?

It works until it does not. Analytical queries scan far more data than transactional ones, compete for the same resources, and can hold locks. The usual result is that application latency degrades whenever somebody runs a report. Routing reporting to a replica is cheap and solves it.

How urgent is upgrading an old MySQL version?

Urgent if it is past its support date, since that means no security patches on a database that usually holds your most sensitive data. Older versions also carry defaults, particularly around character sets and strict mode, that cause real data problems. Upgrades are usually less painful than feared, and the defaults changes are the part to test.