Skip to content

CONCEPT Cited by 1 source

100 ms slow-query threshold

100 milliseconds is the threshold PlanetScale uses to flag an individual query as a candidate for optimisation in its query-statistics report. Queries that run longer than 100 ms are surfaced in the dashboard's slow-query view; queries below are not. It is a product-UX heuristic, not a performance SLO.

Canonical statement

As a starting point, we flag any query running for longer than 100 milliseconds as a candidate for optimization.

— sources/2021-08-31-planetscale-optimizing-sql-with-query-statistics

Three framing choices are deliberate:

  • "As a starting point" — not a final tuning; PlanetScale reserves the right to adjust.
  • "Candidate for optimization" — not a pager alert; not a violation of a guarantee; an invitation to inspect.
  • "Flag" — UI-level decoration, not a throttle or a rejection. The query still runs.

Why 100 ms

The 100 ms value is not arbitrary. It sits at a particular point in the cost-benefit frontier for an OLTP workload:

Query latency Typical UX / system consequence
< 10 ms Imperceptible even in UI request cycles.
10 – 100 ms Often the dominant cost of an HTTP response but acceptable for most synchronous flows.
100 – 500 ms User-perceptible pause; worth investigating.
500 ms – several s Clearly worth optimising or moving async.
> 1 s Usually a bug or a missing index.

100 ms is the point at which queries typically start to be noticeable in the user experience, but still below the point at which everyone has already noticed them. It maximises signal-to-noise for a product that wants developers to act early — before a query becomes an incident.

Not a guarantee, not an SLO

The 100 ms threshold is explicitly not a service level objective. PlanetScale does not commit that customer queries run faster than 100 ms; some queries should take longer (large scans, complex joins). The threshold is just a tripwire for attention — consistent with the service-level objective principle that SLOs and UI heuristics live at different organisational levels.

Threshold lineage

The 100 ms value surfaces repeatedly across later PlanetScale work:

  • The query-digest view in PlanetScale Insights sorts slow queries with a default 100 ms cutoff.
  • The query-tagging threshold in Traffic Control includes a 1-second variant: "at least one query that took more than 1 second, read more than 10k rows, or resulted in an error" — i.e. a second, more-selective tripwire above the 100 ms default.
  • The slow-query-limiter token-bucket uses the same 100 ms threshold as its counter trigger.

The threshold is thus a product-wide constant, consistent across the 2021 feature launch and its 2024+ elaborations.

For context, 100 ms is the same order as:

  • MySQL's default long_query_time (1 s), one order higher and rarely changed — reflects MySQL's conservative-default posture for slow-log inclusion.
  • Postgres log_min_duration_statement — often configured to 100 ms or 200 ms by practitioners.
  • The default Google SRE book's latency SLO guidance for user-facing systems (p99 latency under 200-500 ms).

100 ms is thus aggressive compared to server-engine defaults (which were designed for background analysis of rare anomalies) and conservative compared to user-facing SLOs (which include network and application layers). The sweet spot is deliberate: PlanetScale is a PaaS database telling developers which of their SQL queries deserve a second look — not a MySQL debugger and not a user-latency guard.

Caveats

  • Not all queries over 100 ms are bad. Some workloads (analytical rollups, archival sweeps, batch jobs) have inherently long queries. Flagging them is informational, not prescriptive.
  • Not all queries under 100 ms are fine. A 50 ms query called 10 000 times per second may be more urgent to optimise than a 200 ms query called once per hour. Query statistics surface both metrics — the 100 ms flag is an entry point, not a closed list.
  • The threshold is latency-only. The PlanetScale feature also tracks rows-returned and frequency; a query that runs under 100 ms but returns 1 M rows may still be worth examining.

Seen in

Last updated · 550 distilled / 1,221 read