MySQL,
where it fits.

MySQL isn't our default database — but we work with it when the ecosystem, existing stack, or team experience makes it the right choice. This is when, and why.

Where MySQL fits Storage engines Replication Performance MySQL vs PostgreSQL Managed options

01 / When MySQL is right

Where MySQL fits.

We choose MySQL for these reasons — not because it's the default, but because it's the right tool for the specific situation.

High-read web applications

Product catalogues, content sites, and read-heavy workloads where MySQL's replication topology is well understood and battle-tested.

WordPress and PHP ecosystems

If you're running WordPress, WooCommerce, or a legacy PHP framework, MySQL is the path of least resistance — and works well.

Existing MySQL teams

When your team already knows MySQL deeply, migrating to Postgres for theoretical gains is rarely worth the cost.

Simple relational schemas

Well-normalised schemas that fit cleanly into MySQL's types and constraints — no need for jsonb or extensions.

02 / Storage engines

Four engines. One answer.

MySQL exposes multiple storage engines. In practice, almost everything is InnoDB. The others exist for narrow use cases.

InnoDB

Default for everything

ACID, row-level locking, foreign keys, crash recovery

MyISAM

Legacy — avoid

Table-level locking, no transactions, no crash recovery

Memory

Rarely — session data

Fast, non-persistent, size limited

Four topologies.

MySQL's replication story is its biggest strength. There are four common topologies, and the choice depends on your write load and availability requirements.

Primary-replica

The default. One writer, one or more readers. Asynchronous by default, semi-sync for stronger guarantees.

Group replication

Multi-primary with consensus. Higher write availability, more operational complexity.

Galera / Percona XtraDB

Synchronous multi-master clusters. Popular for HA — we deploy when clients need it.

Cloud-managed

RDS, Aurora MySQL, PlanetScale, or DigitalOcean Managed MySQL. The default for most of our clients.

04 / Performance

Six rules that matter.

MySQL is fast by default. These are the tuning levers that actually move the needle when it isn't.

Index the right columns

Same as any relational DB — WHERE, JOIN, ORDER BY columns need indexes. Composite order matters.

Use EXPLAIN

MySQL's EXPLAIN output is different from Postgres, but tells you the same thing: which index, how many rows, in what order.

Connection pooling

MySQL has a lower connection ceiling than Postgres in some configs. ProxySQL or app-level pooling matter more.

Buffer pool sizing

innodb_buffer_pool_size is the single biggest performance lever. Set to 70–80% of RAM on a dedicated DB host.

Query cache — usually off

MySQL's query cache is deprecated. Use Redis or app-level caching instead.

Partition large tables

Native partitioning by range or hash keeps indexes small and queries predictable.

05 / Side by side

MySQL vs PostgreSQL.

An honest comparison. Both databases run production systems. The choice depends on your team and your constraints.

Feature	MySQL	PostgreSQL
Data types	Standard SQL types	jsonb, arrays, ranges, inet, more
Extensions	Plugins — smaller ecosystem	Extensive — PostGIS, pgvector, pg_cron
Query planner	Simple, predictable	More sophisticated — better for complex queries
Replication	Mature, well-documented	Logical replication is newer but improving
Read performance	Excellent — often faster for simple reads	Excellent — closing the gap
Write throughput	Very high at scale	High — good enough for most workloads
Ecosystem	Huge — old, mature, everywhere	Growing fast, modern, well-loved
Familiarity	Widely known by every PHP dev	Slightly steeper learning curve

06 / Managed options

Where we run it.

Self-hosting MySQL is more work than most teams need. These are the managed options we reach for.

Amazon RDS for MySQL

Managed, familiar, multi-AZ failover. Our default for AWS-based clients.

Amazon Aurora MySQL

AWS-optimised MySQL, faster reads, auto-scaling storage. For high-throughput workloads.

DigitalOcean Managed MySQL

Simple, predictable pricing. Good for smaller clients and non-AWS environments.

PlanetScale

Serverless MySQL with branching. Great for teams that want database branches like git branches.

FAQ

MySQL
questions.

MySQL or PostgreSQL?

Postgres by default for new projects. MySQL when you have an existing MySQL ecosystem, a WordPress-based stack, or a team that deeply knows MySQL. Neither is a mistake — they're just different trade-offs.

Do you use MySQL 8?

Yes. MySQL 8 brought real JSON support, CTEs, window functions, and better defaults. It's the only version we recommend for new work — MySQL 5.7 is out of support.

How do you handle migrations?

Same as any relational DB — version-controlled migrations, applied by CI, zero-downtime changes only. MySQL's DDL locking requires careful planning for large tables.

What about high availability?

RDS Multi-AZ by default. Galera or Group Replication for clients that need on-prem or multi-region write availability.

Do you use MySQL for new projects?

Sometimes — when the ecosystem warrants it. But for most greenfield work, we default to Postgres. MySQL shows up most often when we're extending or modernising an existing MySQL-based product.

Can you migrate MySQL to Postgres?

Yes. It's a common engagement. Data type mapping, application-level changes, and testing make it a phased project — the app stays in production throughout.

Working with MySQL?

Whether you're building on it or migrating off it, we can help.

MySQL,where it fits.