planetscale-traffic-control-recommendations

작성자: planetscale

PlanetScale Postgres 데이터베이스 트래픽 제어 예산 및 규칙을 적용하지 않고 안전한 추천 계획을 수립합니다.

npx skills add https://github.com/planetscale/skills --skill 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.

Suggested default budgets

Use these as recommendation patterns, not as values to apply blindly.

Agent budget

Target: queries tagged source=agent or source=mcp.

Intent: prevent agents from starving application traffic.

Mode: start in warn.

Recommendation: agents should prefer replicas and read-only scopes. Writes require human approval.

Export/reporting budget

Target: feature=export, feature=report, or specific report route/job.

Intent: keep customer-triggered reporting from consuming all database resources.

Mode: start in warn; consider enforce after observation.

Background job budget

Target: worker service, queue, or job tags.

Intent: prevent backfills and retries from starving interactive traffic.

Mode: warn first; enforce only after confirming queue backpressure behavior.

Third-party integration budget

Target: source=integration, partner-specific bounded tags, or route templates for inbound integration calls.

Intent: isolate unpredictable partner behavior.

Mode: warn first.

Known fingerprint budget

Target: specific expensive query fingerprint.

Intent: contain a known pathological query while code or schema fixes are developed.

Mode: warn first unless emergency.

“Each tag value” strategy

When PlanetScale supports applying a budget separately for each unique value of a selected tag, recommend it for bounded tags such as:

  • application
  • service
  • route when normalized
  • job
  • feature
  • source

Do not recommend it for unbounded tags such as user IDs, request IDs, raw tenant IDs, emails, UUIDs, or raw URLs.

Limits and caveats to include

Every recommendation must explain:

  • Traffic Control limits resource use; it does not replace query tuning.
  • It is not a web application firewall.
  • It does not replace application-level rate limits.
  • Limits are guardrails, not exact guarantees for every failure mode.
  • Bad tags create bad rules.
  • Enforce mode can reject queries and affect application behavior.

Output format

For each proposed budget:

  • Budget name.
  • Target branch.
  • Mode: off, warn, or enforce.
  • Matched traffic slice.
  • Rule type: tag, fingerprint, keyspace, query kind.
  • Proposed tags or fingerprint.
  • Limit rationale.
  • Queries seen in Insights that justify it.
  • Safety risk.
  • Test/observe plan.
  • Rollback plan.
  • Approval requirement.

End with:

“No Traffic Control budgets or rules have been created, updated, deleted, or enforced.”

planetscale의 다른 스킬

neki
planetscale
PlanetScale의 샤딩된 Postgres 제품인 Neki에 대한 개요 및 정보. Neki 관련 작업 및 확장 또는 샤딩이 필요할 때 로드합니다...
vitess
planetscale
Vitess 모범 사례, 쿼리 최적화, PlanetScale Vitess 데이터베이스 연결 문제 해결. Vitess 데이터베이스, 샤딩 작업 시 로드…
planetscale-autonomous-execution-mode
planetscale
승인된 PlanetScale 변경 사항을 운영자가 명시적으로 위험을 인지한 경우 단계별 승인 없이 처음부터 끝까지 실행합니다. 다음을 정의합니다…
planetscale-best-practices-matrix
planetscale
엔진별로 어떤 PlanetScale 안전, 관찰 가능성 및 자동화 권장 사항이 적용되는지 결정하기 위한 간결한 기능 매트릭스입니다.
planetscale-change-gates-and-approval-contract
planetscale
PlanetScale, 데이터베이스, 리포지토리, 자격 증명, 네트워크 또는 자동화 변형에 대해 명시적 승인 게이트를 적용합니다.
planetscale-codebase-sqlcommenter-instrumentation
planetscale
PlanetScale에 연결된 애플리케이션 저장소를 검사하고 SQLCommenter 호환 쿼리 태깅 패키지와 규칙을 추천합니다.
planetscale-customer-report-template
planetscale
인벤토리 및 관련 검토 스킬을 실행한 후 최종 PlanetScale 모범 사례 보고서를 생성합니다.
planetscale-mcp-agent-operating-model
planetscale
PlanetScale MCP, Insights, 스키마 권장 사항 및 리포지토리 작업에서 자율적인 프로덕션 변경 없이 안전한 에이전트 동작을 구성합니다.