MySQL is easy to underestimate in modern infrastructure conversations. It is often treated like the older default that everyone should have moved past by now.
That is the wrong framing. The real question is not whether MySQL is fashionable. The question is whether it is the practical choice for the applications you actually run.
In many self-hosted environments, the answer is still yes.
When MySQL is the right fit
Self-hosted MySQL makes sense when your stack includes applications or patterns that already align with it well:
- CMS workloads;
- legacy or compatibility-driven applications;
- tools that assume MySQL out of the box;
- lightweight relational use cases where familiarity matters more than database differentiation.
That is especially true if your stack includes When Self-Hosted WordPress Still Makes Business Sense, because WordPress remains one of the clearest examples of a workload where MySQL is not an awkward choice. It is the expected one.
Why MySQL still shows up in real stacks
Compatibility beats ideology
Infrastructure choices should reduce friction, not prove taste.
If the application you need already works naturally with MySQL, forcing another database into the picture can create more migration work, more uncertainty, and more moving parts than the situation deserves.
It stays simple for common relational workloads
A lot of self-hosted workloads do not need advanced data-layer architecture. They need:
- one database;
- predictable credentials;
- backups;
- stable networking;
- low operational confusion.
MySQL is often enough for that.
It fits the āsupporting databaseā role well
In some stacks, MySQL is not the central data platform. It is the relational store required by a specific application. That is still a valid role.
The database layer does not have to be strategic in every case. Sometimes it just needs to support one system well.
MySQL versus PostgreSQL in this stack
This is where many teams get stuck, but the practical answer is usually simpler than the internet makes it sound.
Use MySQL when:
- the application ecosystem around you already expects it;
- the workload is straightforward;
- compatibility is a bigger concern than standardizing everything on one engine.
Use PostgreSQL when:
- you are choosing a general-purpose default for internal tools;
- multiple services in the stack naturally align with Postgres;
- you want one broader relational base for automation and operations.
That is why When Self-Hosted PostgreSQL Is the Right Default for Internal Tools and this article are not in conflict. PostgreSQL is often the stronger default. MySQL is still the more practical answer in specific, common cases.
A practical starting point
If MySQL is the right tool for the workload in front of you, start with AiratTop/mysql-self-hosted.
The repository includes:
- a standalone MySQL container;
- persistent storage under
./data/mysql; - environment-driven credentials;
- restart, update, and backup helper scripts;
shared_networkcompatibility for services that need direct access.
That makes it easy to use MySQL as a clean supporting service instead of a messy one-off installation.
Where MySQL fits in the AiratTop stack
In this ecosystem, MySQL connects most naturally to:
- When Self-Hosted WordPress Still Makes Business Sense, where it is the natural application database;
- When Self-Hosted n8n Is the Better Choice, where workflows may need to read or write MySQL-backed systems;
- the broader comparison planned in PostgreSQL vs MySQL vs ClickHouse vs Redis vs Qdrant in a Self-Hosted Stack.
This is a good example of a database that earns its place by being operationally convenient and application-aligned.
What MySQL does not justify by itself
MySQL is not automatically the best foundation for every self-hosted environment. If you are building several new internal systems from scratch, standardizing on PostgreSQL may still be cleaner.
The practical mistake is not choosing MySQL. The practical mistake is choosing MySQL by habit when another engine fits the workload better.
Summary
Self-hosted MySQL is still the practical choice when your applications already align with it, especially in CMS and compatibility-heavy environments.
It does not have to be your universal database strategy. It just has to be the right database for the system you are actually running.