Planetscale Vitess Safety Review

Vitess safety review

Purpose

Recommend best practices for a PlanetScale Vitess database. Focus on production safety, deployability, observability, and agent-safe automation. Do not apply any changes.

Primary safety features to evaluate

Safe migrations

Check whether safe migrations are enabled on production and staging branches.

Recommend enabling safe migrations when:

• The branch receives production traffic.
• The team runs DDL outside deploy requests.
• There is no protected branch workflow.
• The application is expected to evolve schema frequently.

Explain the tradeoff: safe migrations reject direct DDL on protected branches and force schema changes through deploy requests. That is a feature, but it can break teams relying on direct production DDL. Treat enablement as a behavior-changing change requiring approval.

Deploy requests

Check:

• Whether deploy requests are used for schema changes.
• Whether administrator approval is required.
• Whether deploy requests are reviewed for data loss, conflicts, lint errors, foreign key problems, charset issues, and shard impact.
• Whether teams use gated deployments for cutover control.
• Whether “deploy instantly” is used and whether the team understands it removes the gated-deployment/revert shape.
• Whether cutover is regularly delayed by long-running transactions.
• Whether deploy request events are subscribed to via webhooks.

Recommend:

• Require deploy requests for production schema changes.
• Enable administrator approval for production deploy requests when there is more than one administrator.
• In a single-admin organization, administrator approval does not stop an agent that acts as that admin: the admin who opens a deploy request can also approve it. If the goal is to keep agents from self-approving, give the agent a separate user, or a service token without deploy request approval permission.
• Prefer normal safe deployments over instant deployments unless the migration is known to be instant-safe and the rollback story is acceptable.
• Use gated deployment when cutover timing matters.
• Treat “force cutover now” as an operator-controlled action for delayed cutovers: it aggressively stops running transactions to complete schema cutover. Recommend reviewing the blocking workload and incident context before use, and only recommend the database-level aggressive cutover default when frequent cutover blocking is understood and accepted.

Schema revert

Check whether the team knows the revert window and whether their incident runbook includes it.

Recommend documenting:

• How to identify a bad schema migration.
• How to revert within the supported window.
• Who is authorized to revert.
• Which application deploy should be rolled back together with the schema revert.

Branch strategy

Recommend a branch topology:

• main or equivalent production branch with safe migrations enabled.
• staging branch based from production with safe migrations enabled.
• Short-lived development branches based from staging.
• Deploy requests from development to staging, then staging to production when appropriate.

Do not create branches without approval.

Query Insights

Review Insights for:

• Slow queries.
• Queries reading too many rows.
• Erroring queries.
• Queries with poor index usage.
• For sharded databases, whether query patterns use relevant vindexes and how vindex usage changes after index or routing changes.
• Unusual query volume.
• Missing SQL comment tags.
• Tag breakdowns when built-in metadata or SQLCommenter tags are present: tag:key:value filtering in the dashboard, and the insights/tags and insights/tags/summaries API endpoints for programmatic breakdowns.
• Deploy correlation data.

Recommend enabling or improving application query tagging so Insights can attribute queries to app, route, controller, action, job, deployment SHA, and feature.