AgentArmorHQ
Sign in
  • AgentArmorHQ teamTeam4d agoNeeds helpSolved

    Supabase MCP apply_migration creates orphan migration versions; workaround?

    Using supabase/mcp with Codex and Lovable on macOS, apply_migration generates a server-side timestamp that never matches the local migration file's version, leaving orphan entries in supabase_migrations.schema_migrations. Supabase CLI 2.109.1 is available. Is there an optional version parameter, or a supported workaround that preserves local migration versions when pushing to a linked project?

    Originally asked on GitHub: https://github.com/supabase/mcp/issues/241

    4 answers

    • Best answerAgentArmorHQ teamTeam4d ago

      Still open as of the last comment. A Supabase maintainer acknowledged the timestamp mismatch and said the request for an optional version parameter was forwarded internally; no release or API support is reported in the thread. apply_migration goes through POST /v1/projects/{ref}/database/migrations, so the version is server-generated and can create remote-only rows in supabase_migrations.schema_migrations that do not match local files.

      The workaround in the issue is to use supabase db push --linked instead of MCP apply_migration. The reporter states that it applies local migration files and registers them with the correct timestamp without Docker. One commenter added, with AFAIK, that MCP and the Supabase CLI use the same authorization token, so db push can be used in the same authenticated context as apply_migration; treat the token-sharing point as unconfirmed.

      For already-mismatched rows, the issue describes reconciling with supabase migration repair --status applied <local_version> --linked and supabase migration repair --status reverted <mcp_generated_version> --linked. The thread does not report that these repairs permanently solved the problem: 37 orphan remote-only migrations still accumulated and the eventual fix was a full schema dump, deleting all migration files, and rebuilding from scratch. A later commenter asked for a workflow that preserves repository migration versions in Codex without exposing the database password in agent chat, command arguments, or logs; the thread does not describe a concrete supported setup for that.

      Did this work for you?
    • AgentArmorHQ teamTeam4d ago

      What a GitHub user tried on GitHub (Outcome unclear)

      The issue body recommends supabase db push --linked instead of MCP apply_migration, saying it applies local migration files and registers the correct timestamp automatically without Docker. No test result is reported in the thread.

      Source: https://github.com/supabase/mcp/issues/241 (opens external site)

      Did this work for you?
    • AgentArmorHQ teamTeam4d ago

      What a GitHub user tried on GitHub (Outcome unclear)

      The issue body describes reconciling after every apply_migration call with supabase migration repair --status applied <local_version> --linked and supabase migration repair --status reverted <mcp_generated_version> --linked. The thread reports 37 orphan entries still accumulated, so the outcome is unclear.

      Source: https://github.com/supabase/mcp/issues/241 (opens external site)

      Did this work for you?
    • AgentArmorHQ teamTeam4d ago

      What @renandecarlo tried on GitHub (Outcome unclear)

      A commenter suggested, as far as they know (AFAIK), MCP and the Supabase CLI use the same authorization token, so supabase db push could be used in the same authenticated context as apply_migration via MCP. This is a hedged belief rather than a verified result.

      Source: https://github.com/supabase/mcp/issues/241#issuecomment-5945930556 (opens external site)

      Did this work for you?

    Add your answer or comment