MySQL

Best for

• ·Web application OLTP workloads with well-defined access patterns via primary key or indexed columns
• ·Systems requiring ACID transactions with row-level locking and predictable single-query latency
• ·High read-to-write ratio workloads served by a primary + multiple replicas with ProxySQL routing
• ·Organizations with existing MySQL operational expertise where migration risk outweighs PostgreSQL feature advantages
• ·Sharded relational workloads at extreme scale using Vitess for transparent horizontal partitioning

Excels when

• ·Query patterns primarily access rows by primary key or narrow composite index: InnoDB's clustered key layout makes these very fast
• ·Read load is 10x+ write load and can be distributed across replicas
• ·Team has ProxySQL expertise to handle connection pooling and replica routing
• ·Write throughput fits on a single primary at up to 40k TPS with tuning

Avoid when

• ·Workload requires complex SQL features: partial indexes, array types, lateral joins, or advanced window functions available in PostgreSQL
• ·Write throughput requires horizontal scaling without a sharding layer: use CockroachDB or Vitess-on-MySQL
• ·Workload is primarily analytical: MySQL's row-oriented storage performs poorly on full-scan aggregation queries

Read scalability

Known failure modes

• ·Replication lag on write-heavy workloads causes stale reads on replicas; GTID lag must be monitored continuously
• ·Long-running transactions holding row locks block subsequent writes on the same rows indefinitely
• ·InnoDB deadlock cycles under high-concurrency mixed read-write workloads; applications must handle ER_LOCK_DEADLOCK and retry
• ·Binary log retention misconfiguration causes disk exhaustion when a replica goes offline and the primary retains binlog for it
• ·Secondary index indirection: a secondary index lookup for a non-covered column finds the primary key, then a second traversal into the clustered index finds the row, doubling B-tree reads on covering-index misses at sustained write/read throughput (see secondary_index_saturation)
• ·Group Replication certification conflicts under high contention cause transaction rollbacks that are invisible to applications not checking for ER_TRANSACTION_ROLLBACK_DURING_COMMIT
• ·Undersized redo log capacity forces InnoDB's fuzzy checkpointing into more frequent synchronous checkpoints, stalling writes; oversizing it extends crash-recovery replay time (see checkpoint_amplification)
• ·Redo log and binlog growth outrunning disk bandwidth or replica apply rate stalls commits and, for the binlog, can exhaust disk if a replica or CDC consumer falls behind (see wal_saturation)

Bottlenecks

• ·Single-primary write path cannot be horizontally scaled without Vitess or application-layer sharding
• ·Secondary index indirection: a covering-index miss requires a second B-tree traversal from the secondary index into the clustered primary key to fetch the row, doubling random reads for that query shape (see secondary_index_saturation)
• ·Connection overhead under high concurrency: MySQL uses one OS thread per connection; ProxySQL is mandatory at >500 concurrent connections
• ·Long transactions hold row locks and inflate InnoDB history list length, degrading read performance for all queries
• ·Binlog-based replication is synchronous commit on primary but asynchronous delivery to replicas: replica lag is inevitable under write bursts
• ·Redo log size vs. checkpoint frequency tradeoff: a small innodb_redo_log_capacity (or the older innodb_log_file_size/innodb_log_files_in_group pair) gives fuzzy checkpointing less room to spread dirty-page flushes and forces more frequent synchronous checkpoints under sustained write load, while a larger redo log extends crash-recovery replay time (see checkpoint_amplification)

Degradation patterns

• ·InnoDB history list length grows when long-running read transactions prevent purge of old row versions: read latency increases as purge queue depth rises
• ·Replication lag accumulates during large batch writes that produce large binlog events; replicas fall behind and stale reads silently increase
• ·Connection storms during primary failover: applications not behind ProxySQL open new connections directly and overwhelm the new primary
• ·Forced synchronous checkpoints under sustained high-write load when the redo log approaches capacity: unlike PostgreSQL's clock-driven checkpoint spikes, this is load-driven, InnoDB's page cleaner flushes more aggressively as redo log space or the buffer pool's dirty-page fraction nears its ceiling (see checkpoint_amplification)

Common topology roles

Outbound: this entity affects