MySQL

MySQL is the world's most widely deployed open-source relational database, a workhorse of web application infrastructure since its first release in 1995. Where PostgreSQL pursued extensibility as a design philosophy, MySQL pursued deployment velocity: the goal was not to be the most capable database, but to be the easiest database to install, configure, and run at scale. This is not a criticism. It is a different theory of what infrastructure should optimize for.

MySQL's original architecture was thread-per-connection: each client connection received its own operating system thread, managed by a lightweight scheduler within the mysqld process. This model was more memory-efficient than PostgreSQL's process-per-connection but less resilient — a misbehaving query could crash the entire server, not merely one connection. MySQL later added thread pools and plugin storage engines, but the core architecture remains throughput-oriented, with fault isolation delegated to the storage engine layer rather than the process boundary.

The Storage Engine Abstraction

MySQL's most distinctive architectural decision is the storage engine abstraction: the SQL layer is separate from the storage layer, and multiple storage engines can coexist in the same server. The default engine since MySQL 5.5 is InnoDB, which provides ACID transactions, row-level locking, and a WAL-based redo log. But MySQL also supports MyISAM (non-transactional, table-level locking), Memory (heap tables), and numerous third-party engines. This is not extensibility in the PostgreSQL sense — it is modularity, a different pattern with different consequences.

The storage engine model means that MySQL's transactional semantics depend on which engine a table uses. A query joining an InnoDB table and a MyISAM table operates across two different consistency models, and the optimizer must be aware of the capabilities of each engine. This is flexibility at the cost of predictability, and it is why MySQL's architecture is harder to reason about than PostgreSQL's monolithic but uniform design.

Replication and the Binary Log

MySQL's replication is log-based, like PostgreSQL's, but the implementation differs in systems-consequential ways. MySQL's Binary Log (binlog) is a logical log of statements or row changes, not a physical WAL of data page modifications. The binlog is designed for replication, not for crash recovery — InnoDB's redo log handles that. This separation creates a two-log architecture that PostgreSQL avoids: PostgreSQL's WAL serves both replication and recovery, while MySQL splits the responsibility across binlog and redo log.

The systems consequence is that MySQL's replication is more flexible — the binlog can be consumed by heterogeneous systems, not merely other MySQL instances — but it is also less consistent. Statement-based replication can produce divergent states on replicas if queries contain non-deterministic functions. Row-based replication is safer but more verbose. And because the binlog and redo log are separate streams, MySQL cannot guarantee that a committed transaction is both durable and replicated in a single atomic write. This is a subtle but real systems weakness.

MySQL in the Cloud Era

MySQL's dominance in the web era — the LAMP stack: Linux, Apache, MySQL, PHP — gave it an enormous installed base and ecosystem. But in the cloud era, MySQL's position has become more contested. Cloud providers offer managed MySQL (Amazon RDS, Google Cloud SQL, Azure Database) that eliminates operational burden but also restricts engine choice and replication access. At the same time, MySQL's ownership by Oracle has created a fork: MariaDB, maintained by MySQL's original creator Monty Widenius, promises a more open future but has fragmented the ecosystem.

The deeper question is whether MySQL's architecture is adequate for modern workloads. Its query optimizer is less sophisticated than PostgreSQL's, its extensibility is more limited, and its replication model has well-known consistency edge cases. Yet MySQL remains the default choice for web applications that need a relational database without needing to understand it. It is the database of "it just works," and that is a valid systems position: not every system needs to be understood, and not every operator needs to be a database architect.

MySQL's success is not a triumph of engineering but a triumph of product design. It won the market by being good enough at the right time, not by being the best at any single thing. This is not a flaw — it is a reminder that infrastructure adoption is driven by deployability, not by correctness. But as systems grow more complex and failure modes more costly, the databases that reward understanding will produce better outcomes than the databases that reward ignorance. MySQL is the database you choose when you want to stop thinking about the database. The question is whether that is still a sustainable choice when the database is the system.