MySQL

What it is

MySQL is the open-source relational database that powered the early web. First released in 1995 by MySQL AB, it ended up at Oracle via the Sun Microsystems acquisition in 2010. It remains the database under WordPress, Drupal, Joomla, Magento, and a generation of LAMP-stack applications, and is the default relational option on every major cloud (AWS Aurora MySQL, Google Cloud SQL, Azure Database for MySQL).

Why people use it

• Battle-tested at scale. Facebook, Booking.com, Uber, and Shopify all run major MySQL fleets. Every operational corner case has been hit by someone before you.
• Easy replication. MySQL’s primary-replica replication is genuinely simpler to set up than Postgres logical replication. Read-replica scaling is the path of least resistance for most teams.
• Cloud-native managed offerings. Aurora MySQL in particular has a separated compute/storage architecture, fast failover, and read replicas without replication lag. It’s one of the strongest managed databases on any cloud.
• Familiarity. The pool of engineers who know MySQL is enormous. Hiring is easy. Documentation, blog posts, and Stack Overflow answers are abundant.

When to use MySQL

• Existing apps already on MySQL or MariaDB — don’t migrate without a reason.
• Read-heavy workloads where horizontal read-replica scaling fits naturally.
• LAMP/LEMP stack applications.
• When AWS Aurora MySQL is on the table (its operational profile is excellent).
• Teams with deep MySQL operational experience.

When not to use MySQL

• New greenfield projects where you’d otherwise pick Postgres. Postgres is more featureful (better JSON, better types, stronger constraints, geospatial via PostGIS).
• Heavy use of advanced SQL features. CTEs and window functions only arrived in MySQL 8.0 (2018); the implementation is good but the Postgres equivalents have a decade-plus head start.
• Geospatial workloads. MySQL has spatial types, but PostGIS is a different league.
• Strong-consistency analytical workloads. Postgres or ClickHouse handle this better.

Notable trade-offs

• Oracle ownership. Some organizations have policies against running Oracle-owned code; MariaDB exists partly to address this.
• Loose defaults historically. MySQL has had a reputation for accepting bad data (truncating strings, accepting invalid dates). STRICT mode and the defaults in 8.0+ have largely fixed this, but legacy schemas may still be loose.
• Replication lag. Async replication can lag under heavy write load. Statement-based replication has determinism gotchas; row-based replication is heavier on the wire.
• JSON support is weaker than Postgres JSONB. MySQL has a JSON type, but indexing is less flexible and operators are more limited.
• Smaller extension ecosystem. MySQL doesn’t have an extension system comparable to Postgres. You can write plugins, but the ecosystem is thinner.

Ecosystem

• Forks. MariaDB (the most prominent fork, by the original MySQL author), Percona Server (drop-in replacement with operational improvements).
• Sharding. Vitess (the system that powers YouTube and Slack) is the reference solution for sharding MySQL.
• Proxies. ProxySQL and MySQL Router for query routing and connection pooling.
• Managed offerings. AWS Aurora MySQL, AWS RDS for MySQL, Google Cloud SQL for MySQL, Azure Database for MySQL, PlanetScale (Vitess-based, now closed-source pivoted), Aiven, DigitalOcean Managed MySQL.