CONCEPT Cited by 1 source
Query priority classification¶
Query priority classification is the upstream step that makes load-shedding feasible: every database query is tagged — at the application layer — with a priority tier that reflects user-perceived importance of the feature issuing the query, not database cost, not SLA, not request rate.
Canonical three-tier scheme¶
Ben Dicken's 2026-03-31 PlanetScale post canonicalises a three- tier partition (Source: sources/2026-04-21-planetscale-graceful-degradation-in-postgres):
| Tier | Definition | Social-media worked example |
|---|---|---|
| Critical | The app is broken without these. If these fail, users have nothing to do and leave immediately. | Authentication, post creation, post fetching, author profiles |
| Important | Noticeable if missing, but the app is still usable. | Comments, post search, direct messaging |
| Best-effort | Nice to have. Users can still use the platform fine if these are degraded. | Like/impression/bookmark counts, trending topics, notifications, analytics dashboard |
Dicken frames tier design as a product-engineering exercise rather than a database-engineering one: "Your tiers will look different depending on your application. The point is to identify what you're willing to shed under pressure so that the things that matter most keep working."
Why priority is not cost, rate, or SLA¶
- Not cost — a
COUNT(*)over an impressions table is cheap per-row but best-effort; an authenticate-and-load- profile sequence is more expensive but critical. Cost and priority are independent. - Not rate — most traffic by count is often best-effort (view-counters, impression-pings, trending-feed refreshes); sorting by "what the most queries are" would tell you to protect the opposite of what matters.
- Not SLA — SLAs are response-time commitments; priority is about what to keep serving at all when capacity is exhausted. A best-effort query can have a tight SLA under normal load and still be the first thing cut under spike.
The correct framing is user-perceived feature importance: would a user notice this is missing? Would they leave?
Tagging mechanism¶
Application attaches a SQLCommenter tag at each call-site:
-- Critical: user's feed
SELECT body, author_id, created_at FROM posts WHERE id = $1
/* category='viewPost', priority='critical' */
-- Best-effort: stats on the post
SELECT COUNT(*) FROM impressions WHERE post_id = $1
/* category='postStats', priority='bestEffort' */
Two tag dimensions at once is typical: a coarse priority axis
for budget selection + a fine category axis for observability
and optional per-category budgets (Source:
sources/2026-04-21-planetscale-graceful-degradation-in-postgres).
Dependency on budget enforcement¶
Classification without enforcement is observability-only. The classification becomes load-bearing when paired with a per-tier resource budget whose dials differ by tier:
- Critical: unrestricted server share, tight per-query cap to catch rogue slow queries.
- Important: bounded server share (e.g. 25%), moderate concurrency.
- Best-effort: low server share (e.g. 20%), low concurrency, live-disable-able under spike.
The priority tag selects which budget applies.
Why three tiers is typically right¶
Most workloads do not need more than three. Two is too coarse (merges "noticeable if missing" into either "critical" or "best-effort" incorrectly); five or more tends to collapse back to three under real operational pressure (operators pick one of two actions under spike: shed best-effort, or shed important- and-best-effort-both). The social-media shape Dicken uses splits cleanly at three.
Seen in¶
- sources/2026-04-21-planetscale-graceful-degradation-in-postgres — Canonical wiki instance. Ben Dicken walks a social-media platform through the critical / important / best-effort partition, maps each to a Traffic Control budget, and demonstrates how the partition makes a 10× load-spike scenario survivable without a user-facing outage.