CONCEPT Cited by 1 source

Write churn¶

Definition¶

Write churn is the rate at which a table's rows are created, modified, and removed, measured independently of the table's steady-state size. A queue table that sees 1,000 inserts and 1,000 deletes per second has very high write churn but near-zero net growth. A log table that sees 1,000 inserts per second and no deletes has the same insert rate but no churn — just growth.

Why the distinction matters¶

In MVCC databases (Postgres, MySQL InnoDB, Oracle), every mutation creates work for the garbage collector, not just for the writer:

Every UPDATE writes a new row version and marks the old one dead.
Every DELETE marks the row dead.
Vacuum must later reclaim every dead tuple.

High churn at steady-state size is the worst case for MVCC: sustained heavy write load with no corresponding table growth signal. Traditional bloat monitoring looks at n_live_tup or disk usage and sees nothing wrong, while n_dead_tup and index bloat grow silently.

Canonical high-churn workloads¶

Job queue tables — every successful job = 1 insert + 1 delete. Table size roughly constant, cumulative work enormous.
Session tables — every login + logout cycle.
Rate-limit counters (non-slotted) — every request increments then periodically resets.
Heartbeat tables — every agent heartbeat UPSERTs a row.
Lock tables — acquire + release cycles.

Why it's dangerous¶

Write churn exposes two distinct failure modes:

Write amplification per mutation — see HOT updates for the Postgres-specific mitigation (fillfactor + narrow tables + un-indexed mutating columns make updates cheap).
Dead-tuple accumulation faster than vacuum can reclaim — see concepts/mvcc-horizon and concepts/postgres-autovacuum.

Both matter independently; a workload can be HOT-optimized (mitigating #1) and still die of horizon-pinned #2 if other workloads on the cluster hold snapshots open.

Seen in¶

sources/2026-04-11-planetscale-keeping-a-postgres-queue-healthy — Griggs names the defining property of a queue table as "most rows are transient. Inserted, read once, and deleted. So the table's size stays roughly constant while its cumulative throughput is enormous." — the canonical statement of write churn on the wiki. The article's central argument is that this shape creates a failure mode orthogonal to the churn rate itself: the database needs not only to keep up with mutations but also to reclaim their debris, and only the latter is contested when other workloads share the cluster.