Planetscale Schema Recommendations Agent Loop

Schema recommendations agent loop

Purpose

Use PlanetScale schema recommendations as high-quality input to agents. Convert recommendations into safe implementation plans, issues, branches, migrations, or pull requests. Do not apply recommendations directly.

Inputs

Collect:

• Open schema recommendations.
• Recommendation type.
• Affected table, keyspace, schema, and query pattern.
• Suggested DDL.
• Supporting Insights evidence.
• Application repository and migration system.
• Engine: Vitess or Postgres.
• Target branch.

Recommendation types to recognize

• Add index for inefficient query.
• Remove redundant index.
• Prevent primary key ID exhaustion.
• Drop unused table.
• Upgrade legacy charset or collation.
• Other DDL recommendation.

Triage questions

For each recommendation, answer:

• Is this still open and relevant?
• Which query patterns triggered it?
• Which application code paths generate those queries?
• Is the recommendation safely expressible in the application’s migration framework?
• Does the ORM/schema source of truth need to change?
• Can it be tested on a non-production branch?
• What is the expected impact on reads, writes, storage, and deploy time?
• Is there a rollback or revert path?
• Is there a competing recommendation or migration?

Engine-specific implementation path

Vitess

Recommended path:

• Create or use a development branch.
• Apply the schema change to that branch only after approval.
• Open a deploy request only after approval.
• Use deploy request review to inspect schema, shard impact, data-loss warnings, lint errors, and conflicts.
• Use normal safe migration path unless instant deployment is explicitly justified.
• Deploy only after approval.
• Monitor Insights and anomaly state after deployment.

Default output before approval: issue or PR with migration proposal, not a live deploy request.

Postgres

Recommended path:

• Convert DDL into the application’s migration framework where possible.
• Test against a non-production branch.
• Run application tests and relevant query checks.
• Open PR.
• Apply production migration only after approval.
• Use backups/PITR runbook as recovery plan, not as a substitute for migration review.

Default output before approval: migration PR or issue, not production DDL.

Codebase correlation

When a repository is available:

• Search for the table and column names.
• Search for ORM model definitions.
• Search for migrations.
• Search for query fingerprints, route tags, job names, and controller/action names from Insights.
• Identify whether the recommendation should be implemented in database DDL, ORM schema, raw migration, or application query code.

Safety checks before proposing implementation

Block direct application when:

• The recommendation is stale or already addressed.
• The affected table is small enough that the benefit is unclear.
• The index would be redundant with an existing index.
• The index would hurt write-heavy workloads without enough read benefit.
• The table appears unused but repository references are ambiguous.
• Dropping a table or index lacks owner confirmation.
• The migration framework has a different schema source of truth.
• The recommendation targets production and no branch/test plan exists.

Output

For each recommendation, produce:

• Recommendation ID/number.
• Type.
• Severity and expected benefit.
• Evidence from Insights.
• Affected schema.
• Suggested DDL.
• Application code owner or likely location.
• Safe implementation path.
• Validation plan.
• Rollback/revert plan.
• Approval requirement.

End with:

“No schema recommendations have been applied.”