Ben Dicken [@BenjDicken] | March 31, 2026Not all traffic is created equal. When a database is overwhelmed, you want the important queries to keep executing, even if that means shedding lower-priority work. This is a much better outcome than the alternative: a total database outage.PlanetScale's Traffic Control makes this feasible at the database level by introducing resource budgets. These let you apply strict limits on slices of traffic, protecting resources for high-priority queries even when there's a surge in requests.I'll run through exactly how this works in the scenario of running a social media platform. The same principles apply to any application with a wide variety of traffic types.The scenarioOperating a social media platform involves quite a few different types of queries, each corresponding to different app features:AuthenticationFetching post contentFetching user profile informationSubmitting new postsFetching + updating like, impression, and bookmark countsCommentingLoading trending topicsDirect messagingUnder normal load, a well-designed system allows every query to complete quickly. There is no need to prioritize one type of query or feature over another. But when a viral event, bad deployment, or DDoS attack introduces a load spike, these queries start competing for the same finite pool of database resources. Every query has an equal shot at consuming CPU and I/O, which means a flood of impression-count queries can starve the ones that users care most about, like authenticating and loading their timeline.From the user's perspective, such database issues can make the application completely unusable. They can't read posts, they can't navigate, and they leave. Had you instead just stopped serving lower-priority components of the app for a few minutes, like impression counts and notifications, users would barely notice and stay on your platform.Categorizing your trafficTo solve this with Traffic Control, the first step is to categorize and prioritize all Postgres traffic.Critical: The app is broken without these. Authentication, post creation, post fetching, author profiles. If these fail, users have nothing to do on your application and will leave immediately.Important: Noticeable if missing, but the app is still usable. Comments, post search, direct messaging (oh hello 𝕏.com).Best-effort: Nice to have. Like, impression, and bookmark counts, trending topics, notifications, analytics dashboard. Users can still use the platform fine even if these features are degraded.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.Now that we know the priority of our application's product features, we need a way to identify these in our database queries. Fortunately, a standard exists for sending metadata along with queries: sqlcommenter. This standard allows clients to append a comment with key-value pairs to SQL statements.For example, a query tagged with a priority tier looks like:SELECT body, author_id, created_at FROM posts WHERE id = $1