Skip to content

CONCEPT Cited by 1 source

Write throughput ceiling

Write throughput ceiling is the point at which a database primary can no longer absorb incoming writes at the rate the workload demands. It is one of the three canonical sharding-trigger signals — alongside data-size overflow of working-set RAM and read-throughput overflow of read-replica capacity.

Symptom chain

Berquist (sources/2026-04-21-planetscale-guide-to-scaling-your-database-when-to-shard-mysql-and-postgres) canonicalises the symptom ordering. Replication lag is the leading indicator; IOPS saturation is the lagging indicator:

"When the primary is maxed on IOPS, writes will become less performant. Usually before that, however, replication lag becomes a problem. While there have been significant improvements in replication within MySQL clusters, there will always be a small amount of delay between the time the data is written to the primary and that same data is written to a replica."

The chain:

  1. Replication lag rises. Replicas can't keep up with the primary's write rate. Read-your-writes queries routed to replicas see stale data; downstream consumers (CDC, analytics replicas, backup workers) fall behind.
  2. Application-visible staleness / errors. "when replicas fall behind the primary, this can look like inconsistent or stale data to your users, and may also result in errors if your application expects to be able to read data that it has just written."
  3. Primary IOPS saturation. The primary itself can no longer keep pace; write latency climbs.
  4. Operational-task slowdowns. "Other database operations like schema changes and batch jobs will be slower as well." Schema migrations time out, backup throughput drops, replica bootstrap takes longer.

Why replication lag is the leading indicator

Replication is asynchronous (or semi-sync): a replica applies writes after the primary. When the primary's write rate exceeds single-threaded-replay capacity on the replica (common in MySQL because SQL_THREAD is single-threaded per source), the replica falls behind even when the primary's IOPS budget still has headroom. So replication lag degrades before primary saturation — a useful early-warning signal.

Mitigations — ordered by escalation

  1. Vertical scaling — bigger primary, more IOPS headroom.
  2. Faster substrate — direct-attached NVMe (PlanetScale Metal) has no artificial IOPS cap; network-attached storage (RDS, CloudSQL) hits it earlier. "With PlanetScale Metal, write throughput is significantly less of a concern … substantially higher IOPS." (Source: sources/2026-04-21-planetscale-guide-to-scaling-your-database-when-to-shard-mysql-and-postgres).
  3. Application-side write reduction — batching, buffering, write coalescing; read replicas do not help the primary absorb writes.
  4. Write sharding via horizontal sharding — split the write rate across N primaries. Each shard absorbs roughly total_writes / N.

Note: read replicas do not raise the write ceiling. Adding replicas increases read capacity but every write still goes through the single primary. The only way to scale writes beyond a single primary is to remove the single-primary assumption — either via horizontal sharding or via a multi-primary system.

  • vs IOPS throttle on network storage: IOPS throttle is the substrate-level cap (e.g. EBS's provisioned IOPS); write-throughput ceiling is the database-level symptom that the substrate + replication topology can no longer absorb the workload. Substrates with higher IOPS headroom push the ceiling further out.
  • vs replication lag: replication lag is one symptom of the ceiling (the leading one). The ceiling is the underlying capacity limit.

Seen in

Last updated · 347 distilled / 1,201 read