Skip to content

CONCEPT Cited by 1 source

Hot row protection

Definition

Hot row protection is a Vitess query-serving safety feature that limits the concurrent write amplification against a single hot row before the contention reaches the underlying MySQL instance. When too many writers target the same row, Vitess throttles or queues the excess at the tablet tier so that row-level lock contention on the MySQL side doesn't cascade into whole-cluster stalling.

Why it matters

On a row-locking engine like InnoDB, a hot row triggers a well-known failure shape:

  1. Writer A takes an exclusive lock on the row and starts its transaction.
  2. Writers B, C, … N queue behind A's lock.
  3. A's transaction takes slightly longer than usual — maybe a slow disk, a competing workload, a secondary- index update — and the queue grows.
  4. Every queued transaction holds a connection. When the connection pool is exhausted, unrelated queries against other rows also stall because they can't get a connection.
  5. The hot-row contention has become a full-cluster incident.

Without intervention the failure cascades. Hot row protection intervenes before step 4 by rejecting or queueing excess writers at the proxy tier so MySQL never receives more concurrency than it can absorb.

Canonical framing

"Vitess provides safety features like automatic row limits, hot row protection, query consolidation and non-blocking schema changes which reduce the likelihood of high load bringing down the database. These are all features that vanilla MySQL cannot and does not provide." (Source: sources/2026-04-21-planetscale-on-vitess.)

Relation to other hot-row mitigations

Hot rows are a design-time problem with layered mitigations — hot row protection is the last-resort guardrail at the database tier:

  1. Application-level redesign — [[patterns/slotted- counter-pattern|slotted counter]] (shard a hot counter across N rows + sum at read time) eliminates the hot row entirely.
  2. Schema redesign — split hot columns to their own row so contention is scoped.
  3. Queue-based write coalescing — batch writes into periodic aggregated updates upstream of the database.
  4. Hot row protection (this page) — when the application cannot redesign in time, Vitess caps the blast radius at the proxy tier.

The first three are cheaper if you can do them. Hot row protection is the safety net for when the hot row appears in production before the redesign is available.

Caveats

The 2021 post names the feature but does not disclose:

  • The detection mechanism (query-hash? write-set analysis? row-key fingerprint?).
  • Whether the throttle is reject-with-error or queue-and-retry.
  • The concurrency cap or how it's tuned per cluster.
  • Interaction with transaction throttler (later canonicalised in the throttler trilogy — hot row protection may be its direct predecessor or a sibling mechanism).
  • How it composes with query consolidation on reads of the same hot row.

Like automatic row limits, deeper specification needs a later Vitess- internals post to disclose the mechanism.

Seen in

  • sources/2026-04-21-planetscale-on-vitess — Deepthi Sigireddi (PlanetScale, 2021-07-20) names hot row protection as one of four Vitess safety features that "vanilla MySQL cannot and does not provide". Frames it as part of the "even a small-scale database deployment can benefit hugely from deploying Vitess over MySQL" argument — you don't need Slack-scale sharding to get value from the MySQL-plus-safety- features substrate.
Last updated · 470 distilled / 1,213 read