planetscale-traffic-control-recommendations

Database Traffic Control recommendations

Purpose

For PlanetScale Postgres, recommend Traffic Control budgets and rules that protect critical traffic from runaway queries, traffic spikes, batch jobs, agents, and third-party integrations. Do not create or change budgets without approval.

Preconditions

Run this skill only for PlanetScale Postgres.

Before recommending rules, inspect:

• Current budgets and rules.
• Insights query patterns.
• Current query tags.
• Application routes and jobs.
• Known critical paths.
• Known expensive non-critical paths.
• Active incidents or recent anomalies.

If query tags are missing, recommend tagging first unless a fingerprint-specific rule is clearly needed for an immediate known offender.

Candidate traffic slices

Look for:

• Exports.
• Reports.
• Search endpoints.
• Admin dashboards.
• Backfills.
• Workers and queues.
• Webhooks from third-party systems.
• BI tools.
• Agent-generated read queries.
• High-frequency polling.
• Known expensive query fingerprints.
• Customer-triggered endpoints with high variance.

Budget modes

Recommend in this order:

1. warn mode first for normal rollout.
2. Observe warnings and false positives.
3. Tune tags, fingerprints, and thresholds.
4. Move to enforce only with explicit approval and an emergency rollback path.

Do not recommend starting directly in enforce unless there is an active incident and the operator explicitly asks for emergency mitigation.

Rule strategy

Prefer tag-based rules when tags are stable and bounded:

• source=agent
• source=bi
• feature=export
• feature=report
• route=/admin/reports
• job=DailyBackfill
• service=analytics-worker

Use fingerprint rules when:

• A specific known query pattern is dangerous.
• Tagging is missing or unreliable.
• The query source is hard to attribute.

Use a separate budget for each materially different traffic class.

Do not combine unrelated traffic in one budget because it hides who is consuming the budget.