Mohamed KEITA
Note #7•4 min read

Why MySQL / InnoDB Do Not Solve the Problem

MySQL has been a cornerstone of web infrastructure for more than two decades. Its ubiquity, simplicity, and community ecosystem have made it a go-to choice for traditional web applications. But MySQL and more specifically its default storage engine, InnoDB was designed in a very different era: the late 1990s and early 2000s, when hardware, network architecture, and application workloads looked radically different from today.

This note explores why MySQL/InnoDB struggles in constrained or distributed environments, why its architectural foundations limit its adaptability, and why it cannot fully address the challenges posed by modern local-first, CPU-first, or unreliable network deployments.

Architectural Heritage of the 1990s

MySQL began as a lightweight, fast database optimized for simple read-heavy workloads. Over time it evolved, but its design roots remain visible:

  • assumptions of stable servers with direct-attached storage,
  • low write concurrency,
  • predictable local networks,
  • workloads centered on indexing and point queries.

Even InnoDB, introduced later as a transactional storage engine, carries forward this early philosophy.

MySQL’s original architecture emphasized simplicity and speed over robustness and scalability. While this was appropriate for the web of 2003, it poses challenges for modern distributed systems and constrained edge deployments.

Limitations of InnoDB

InnoDB introduced ACID transactions, MVCC, and crash recovery — significant improvements over earlier MyISAM engines. But the way it implements these features creates structural constraints.

The Doublewrite Buffer

InnoDB cannot rely solely on the OS or the filesystem for atomicity. To avoid corruption during partial writes, it uses a doublewrite buffer:


Page modified
↓
Write page to doublewrite buffer
↓
Write page again to final tablespace

This mechanism doubles certain write operations, increasing write amplification and I/O pressure — problematic in environments with limited disk throughput.

Fragmentation and Page Management

InnoDB stores data in pages, but frequent updates and deletes cause fragmentation:

  • pages become sparsely populated,
  • secondary indexes grow excessively,
  • purge operations must clean old row versions.

This results in unpredictable storage growth and periodic maintenance that competes with the main workload.

Heavy Background Processing

To maintain consistency and performance, InnoDB relies on:

  • background purge threads,
  • adaptive hash index maintenance,
  • change buffering,
  • redo log flushing.

On limited CPUs, these background operations can compete with application queries, increasing latency variability.

Replication and Consistency Challenges

MySQL replication is asynchronous by default:


Primary → binary log → replica

This leads to replication lag, especially under high write rates or high network latency. In distributed or WAN environments, this lag becomes:

  • unpredictable,
  • inconsistent across replicas,
  • difficult to quantify for applications.

Semi-sync replication exists, but it:

  • increases commit latency,
  • still does not guarantee strict consistency in all cases,
  • depends heavily on network performance.

MySQL was designed for single-region setups, not global or intermittent networks.

Limited Scaling Outside the Cloud

Horizontal scaling of MySQL generally requires:

  • manual sharding,
  • middleware (Vitess, ProxySQL),
  • cloud-specific solutions (Aurora, PlanetScale),
  • operational expertise that many teams lack.

These systems work — but they are layered on top of MySQL, not native to it. And they assume:

  • reliable networking,
  • multiple stable nodes,
  • operators who can manage failover and recovery.

For small teams, edge deployments, or environments with weak infrastructure, these assumptions break down.

MySQL’s default behavior still reflects a single-node architecture where:


Scaling = bigger machine, faster SSD, more RAM

This approach is unsuitable in local-first or distributed-by-necessity environments.

Conclusion

MySQL and InnoDB are powerful tools when used in the context for which they were designed: centralized servers with reliable hardware and networks. But their architectural foundations — doublewrite buffering, page fragmentation, asynchronous replication, and single-node scaling assumptions — make them ill-suited for constrained environments, unstable networks, or distributed workloads.

Understanding these limitations is essential when deciding whether MySQL is appropriate for a particular workload, or when exploring alternative architectures optimized for constrained and distributed environments.

Recommended References

  1. Documentation MySQL — InnoDB Architecture
  2. Oracle Whitepaper — InnoDB: Design and Architecture
  3. Percona — InnoDB Performance Tuning
  4. MariaDB KB — Replication & Consistency
  5. Vitess — Sharding MySQL at Scale