SupaForge vs. Flyway / Liquibase

How Flyway and Liquibase Work

Flyway and Liquibase are proven migration tools. They track which changes have been applied to a database and apply the rest in order. They solve applying known changes reliably.

They don't set out to find unknown changes: a policy edited in the dashboard, a grant added in a SQL session, an auth setting changed in one project.

Different Problems, Complementary Tools

• Flyway / Liquibase: "Apply these changes to the database."
• SupaForge: "What actually differs between these two environments - and fix it."

Using Them Together

Keep writing intentional changes as migrations, and use SupaForge to catch everything that happened outside them - after each deploy, on a schedule or in CI. If you need Flyway or Liquibase migrations generated from a diff, DBDiff, the engine under SupaForge's schema check, writes them directly.

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

When Flyway / Liquibase Is Enough

If nobody uses the dashboard or runs ad-hoc SQL, and every change goes through version-controlled migrations, a migration tool may be all the schema needs. Auth settings, storage and Edge Functions are still outside it.

Summary

Flyway and Liquibase apply the changes you write. SupaForge finds the ones nobody wrote, across the whole Supabase project, and fixes them - a natural complement in a production workflow.