It’s easy to assume that MySQL is the default database you eventually grow out of. A stepping stone. A starting point before you “graduate” to Postgres, or jump into something more exotic.
And yes, there are reasons to pick other systems. Postgres is more standards-compliant. SQLite is great for local apps. Some teams want column stores, document models, or full-text search baked in. That’s fine.
But after working with MySQL in production and occasionally comparing it with Postgres and others, across different workloads, I keep coming back to the same conclusion:
MySQL still holds up.
And for a surprising number of use cases, it’s not just “good enough” — it’s better.
Here’s why.
MySQL fails in simple ways
That might sound like a strange compliment, but it matters. When something goes wrong in MySQL — a bad query plan, a lock, a missing index — the symptoms are usually obvious, and the fix is rarely a mystery. Compare that with some Postgres behaviors (like silent performance regressions from a bloated autovacuum backlog) and you start to appreciate a system that’s more predictable, even if it’s a little rougher in theory.
Replication is boring — and that’s a good thing
MySQL’s native replication (especially with GTIDs) isn’t perfect, but it’s mature and well-understood. Need to promote a read replica? No third-party tooling required. Want to tail binlogs? It’s trivial. You can wire it into backup pipelines or use it for low-effort analytics replication. It’s all… just there. That simplicity is underrated.
The ecosystem is practical
Want a backup solution? Use mysqldump, mysqlpump, or xtrabackup. Want a client? Dozens of stable ones exist. Observability? Tools like Percona Monitoring and PMM give you deep insight into slow queries, buffer pools, lock contention — without setting up half a cloud stack.
You don’t need to build a lot around MySQL. You just use it.
Performance is still very competitive
People underestimate how fast MySQL can be when tuned correctly. Especially with InnoDB and well-designed indexes, it handles read-heavy and write-heavy workloads more gracefully than it gets credit for. Add in options like MEMORY tables or partitioning (used carefully), and it scales surprisingly well for OLTP systems.
It teaches you to be intentional
MySQL doesn’t assume much. That forces you to understand what you’re doing — which charset you’re using, how your joins are working, why a certain query plan is chosen. You’re closer to the metal in some ways. And while that can be annoying at first, it also makes you a better engineer in the long run.
None of this is about hype. MySQL isn’t trendy. It doesn’t get much love in conference talks. But in practice? It gets the job done, and gets out of your way.
That might not sound revolutionary — but when you’re running systems that actually need to stay up, sometimes that’s exactly what you want.