db_migrate

Inputs

{
  "sql":   "create table posts (id uuid primary key, ...);
            alter table posts enable row level security;
            create policy ...",
  "label": "add posts table"
}

The RLS gate

When the backend provider is Supabase, Neon, or PlanetScale — i.e. any shared-DB tenant — the tool refuses any migration that creates a table without both ENABLE ROW LEVEL SECURITY and at least one CREATE POLICY statement. This is the RLS gate documented in docs/QUALITY-STANDARDS.md, and it exists because a public anon key against a no-RLS Supabase table is a data leak waiting to happen.

{
  "isError": true,
  "content": [{
    "type": "text",
    "text": "db_migrate rejected: shared-DB provider supabase requires ENABLE ROW LEVEL SECURITY and a CREATE POLICY on every new table (posts). Add RLS policies to the migration and call this tool again."
  }]
}

How it applies (and when it does not)

When your Supabase project is connected via OAuth, db_migrate runs the validated SQL against your database (inside a transaction, using your project's own Management-API token — which stays server-side and never reaches the model), nudges PostgREST to reload its schema, writes the exact applied SQL to supabase/migrations/<timestamp>_<slug>.sql, and regenerates integrations/supabase/types.ts from the new schema. The schema change is live immediately — no manual step. Every apply is audited and capped per session.

It does NOT auto-apply in these cases — instead it writes a reviewable .sql you apply yourself via the SQL editor:

• Destructive DDL (DROP / TRUNCATE / DELETE without WHERE / GRANT / REVOKE / ALTER … DROP|RENAME) — you review the data loss first.
• Projects connected by pasted keys (no OAuth token). Reconnect via Supabase OAuth in Services → Cloud to enable auto-apply.
• The RLS gate failing — a table without Row Level Security + a policy is rejected before anything runs.