SupaForge vs. Manual SQL Diffing

The Problem with Manual SQL Scripts

Most Supabase teams start by replaying changes by hand. Someone adds a column in staging, tweaks a policy or enables a provider, then writes the SQL - or clicks through the dashboard - to do the same in production.

It fails in familiar ways:

• Human error - a forgotten default, a policy left out, statements in the wrong order.
• Invisible drift - dashboard changes nobody remembered to replay, piling up over weeks.
• Only the schema - grants, auth settings, storage, cron jobs and Edge Functions rarely make it into hand-written scripts.
• No way back - a hand-written change rarely comes with its reverse.

What SupaForge Does Differently

SupaForge compares two live environments and reports every difference, across the whole project - including the ones nobody knew about. Then it writes and applies the fixes: in dependency order, in one transaction, with anything destructive held back until you ask for it.

Quick Start

npm install -g @akal/supaforge

{
  "environments": {
    "staging": {
      "dbUrl": "$STAGING_DATABASE_URL",
      "projectRef": "STAGING_REF",
      "accessToken": "$SUPABASE_ACCESS_TOKEN"
    },
    "production": {
      "dbUrl": "$PRODUCTION_DATABASE_URL",
      "projectRef": "PROD_REF",
      "accessToken": "$SUPABASE_ACCESS_TOKEN"
    }
  },
  "source": "staging",
  "target": "production"
}

supaforge diff

supaforge diff --apply --dry-run

supaforge diff --apply --prove

When Manual SQL Still Makes Sense

Backfilling a column from an external API, or reshaping data across tables, is still a job for a hand-written migration. SupaForge catches the drift you didn't write a script for; it doesn't replace the migrations you mean to write.

Summary

Replaying changes by hand is error-prone, rarely goes beyond the schema and gets harder as the team grows. SupaForge finds every difference across the project and applies the fixes safely - locally, in CI or on a schedule.