CONCEPT Cited by 1 source

Automatic row limit¶

Definition¶

An automatic row limit is a Vitess query-serving safety feature that caps the maximum number of rows a single query can return at the tablet level, independent of whether the application asked for a limit. If a SELECT would exceed the cap (for example a missing WHERE clause against a 100M-row table, or a scatter-gather that aggregates too many shard-local rows into VTGate memory), Vitess truncates the result (or refuses to execute, depending on configuration) rather than letting the query complete.

Why it matters¶

A single unbounded SELECT on a large table can:

Consume enough memory on the database that other queries are pushed out of the buffer pool.
Saturate the network between the database and the application for minutes, preventing every other query from making progress.
Cause cascading timeouts upstream if the application's connection pool is exhausted waiting for the giant result.

On vanilla MySQL there is no native protection against this shape — the max_allowed_packet cap limits single-row size, not total row count, and sql_select_limit is a session variable that applications can override. Automatic row limits move the guardrail into the database-proxy tier where applications cannot disable it by accident.

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.)

PlanetScale's 2021 positioning places automatic row limits alongside hot row protection, query consolidation, and non-blocking schema changes as the four canonical Vitess-over-MySQL safety features that "even a small-scale database deployment can benefit hugely from".

Relation to other guardrails¶

Distinct from LIMIT clauses in application SQL — application-supplied LIMIT is advisory and can be omitted. Automatic row limits apply whether or not the application requested one.
Distinct from query consolidation — consolidation deduplicates concurrent identical queries; row limits cap the size of any single query.
Distinct from hot row protection — hot-row protection caps concurrent writes to a single row; row limits cap result-set size.
Composable with scatter-gather — for fan-out queries, the cap can apply either per-shard-local or post-merge at VTGate; PlanetScale doesn't specify which in the 2021 post.

Caveats¶

The 2021 post names the feature but does not disclose:

The default row-limit value or how it's configured.
Whether exceeding the cap truncates silently, raises an error, or routes to a slower path.
Per-query vs per-session vs per-application scope.
Interaction with streaming reads ( VStream) where the workload intends to ship many rows by design.
How it interacts with query tags for per-workload customisation.

Deeper canonicalisation of the mechanism requires a later Vitess-internals post (Harshit Gangal / Deepthi Sigireddi altitude). The 2021 Sigireddi post gives the existence and motivation but not the spec.

Seen in¶

sources/2026-04-21-planetscale-on-vitess — Deepthi Sigireddi (PlanetScale, 2021-07-20) names automatic row limits as one of four Vitess safety features that "vanilla MySQL cannot and does not provide". The framing is a launch-era positioning argument: small- scale deployments benefit even without sharding because the MySQL-plus-safety-features substrate is strictly safer than MySQL alone.