migration file

migration file — a timestamped .sql file under supabase/migrations/ that captures one schema change (a CREATE TABLE, an added column, a new policy) and is the versioned source of truth for your Postgres schema.

Each file is prefixed with a UTC timestamp so migrations replay in a deterministic order. The Supabase CLI applies any file newer than the last recorded version, then writes that version to the supabase_migrations.schema_migrations table on the destination.

supabase/migrations/
├── 20260101120000_create_profiles.sql
├── 20260103084500_add_avatar_url.sql
└── 20260110160000_enable_rls_profiles.sql

The gap to watch: anything you create by hand in the dashboard SQL editor never lands in a migration file. That table, function, or policy exists in the running database but not in your version history, so supabase db push on a fresh project will not recreate it. This is exactly why migrating a Lovable Cloud project cannot rely on migration files alone — much of the schema was created interactively and must be reconstructed by introspecting information_schema and pg_catalog. See schema replay for how that reconstruction works, and pg_dump for the tool you would normally reach for but cannot run inside an Edge Function or the browser.

If you do keep clean migration files, keep them. They are the most reliable record of intent, and applying them on the destination avoids guessing at defaults, sequence resync values, and constraint names.