CONCEPT Cited by 2 sources

Hot shard write frontier¶

A hot shard write frontier is the specific failure mode where all new inserts into a horizontally-sharded table target the same shard because the shard key is monotonic in insertion order and the sharding strategy is range-based (or any scheme that keeps adjacent key values on the same shard). Every append pins to the shard owning the current high-water mark; the other N−1 shards see zero write traffic while that shard saturates.

The canonical trigger¶

Applies whenever a log-style / append-only table is range-sharded on a monotonic column. Ben Dicken's canonical worked example on a hypothetical workout-tracking app's exercise_log table:

"One option would be to shard based on a hash of the log_id column. Each time we need to write a new exercise_log row, we would generate the ID for the row, hash the ID, and then use this hash to determine which shard to send the row to. Since a hash is used, this provides a (roughly) even distribution of data across all of the shards. There is a problem with this though: the logs for any given user will be spread out across all shards." (Source: sources/2026-04-21-planetscale-dealing-with-large-tables)

But replace log_id-hashing with log_id-range-sharding — or created_at-range-sharding, or auto-increment-primary-key range-sharding — and the write frontier collapses to one shard at a time.

Why it happens on log-style tables specifically¶

Log-style tables (exercise_log, events, audit_log, page_views, clicks, messages) share three properties that together guarantee a write frontier under range sharding:

Append-dominant workload — inserts far outnumber updates/deletes.
Timestamp or auto-increment primary key — the natural shard-key candidate is monotonic.
High insert rate — otherwise the hotspot wouldn't matter; but the whole reason you're sharding a log-style table is that inserts are the dominant load.

The combination means: any monotonic key sharded by range puts 100% of writes on the top-range shard. This is the structural reason created_at-range-sharding is almost always wrong for log-style tables.

The `log_id` vs `user_id` teaching example¶

Dicken's post names a second variant of this problem: hash-sharding by log_id distributes writes evenly but scatters reads:

"This means that any time we need to query the log history for one user, we might need to access data on many or all of our MySQL instances. This will be terrible for performance." (Source: sources/2026-04-21-planetscale-dealing-with-large-tables)

Three sharding choices, three different failure modes on the same exercise_log table:

Shard key + strategy	Write distribution	Read distribution (per-user history)
`log_id` (range)	Write frontier — all writes to top-range shard	Point lookup by `log_id` → single shard; per-user scan → cross-shard
`log_id` (hash)	Even — hash scatters monotonic IDs	Per-user scan → scatter-gather (all shards)
`user_id` (hash)	Even — many users writing in parallel	Per-user scan → single shard ✓

The third option is the query-pattern-aligned choice. Because the dominant query on a per-user log table is "all logs for user X", user_id is the shard key; hashing ensures even distribution; co-location of a user's rows on one shard makes the read fast.

Mitigations¶

Hash the monotonic key — hash sharding scatters monotonic inputs across shards by construction. Acceptable if range scans on the shard key aren't the dominant query; common choice for log-style tables when the primary query is point-lookup or per-entity scan.
Re-axis to a high-cardinality, non-monotonic column — for per-user / per-tenant / per-device log tables, shard by the entity ID instead of the log ID. Distribution is even (assuming many entities), and per-entity queries route to a single shard.
Pre-split ranges forward — for range-sharded time-series tables where range-scan efficiency matters, pre-create empty future shards so new inserts spread across multiple shards based on a sub-partitioning scheme (e.g. (region, timestamp)). The write frontier still exists within a region but is divided by region count.

The wiki's default production recommendation for log-style tables is the second option: shard by the entity the log queries are about, not by the log ID itself.

Relation to the general hot-key phenomenon¶

A hot key is any single shard-key value that takes a disproportionate share of traffic; a hot shard write frontier is the temporally-specific case where the hot key is "whatever the current high-water mark is" rather than a fixed value. The mitigations overlap (hashing, re-axis), but the write frontier has the additional property that changing the monotonic key (e.g. UUIDv7, Snowflake ID) doesn't fix it by itself — you have to change either the key or the sharding strategy.

Seen in¶

sources/2026-04-21-planetscale-dealing-with-large-tables — Ben Dicken's exercise_log worked example names the log_id vs user_id shard-key choice as the canonical teaching illustration. The post frames hash sharding by log_id as "terrible for performance" on per-user reads, and hash sharding by user_id as the corrective — implicitly disclosing the write-frontier problem that range sharding on log_id would additionally have produced.
sources/2026-04-21-planetscale-database-sharding — Dicken's later primer canonicalises the same phenomenon explicitly via the range-sharding-on-user_id walk-through: "this doesn't produce a very good distribution of the data, as most of the rows are assigned to shard 1" when auto-increment IDs are range-sharded. Also canonicalises the corrective: hash sharding as the default.