Lovable ↔ Supabase: migrations re-run due to timestamp mismatch in schema_migrations

[JoeJoe1313]

Bug report

 

• [x] I confirm this is a bug with Supabase, not with my own application.
• [x] I confirm I have searched the Docs, GitHub Discussions, and Discord.  

Describe the bug

  Supabase tracks applied migrations using the schema_migrations table where:  

• version is a timestamp (expected to match the {timestamp} prefix of migration filenames like {timestamp}_{uuid}.sql)
• statements stores the SQL content   When applying migrations, Supabase matches only by version (timestamp) between the migration files and the rows in the migrations table. If a version exists in the table, the migration is considered applied and skipped even if the file contents have changed. If a file’s timestamp does not exist in the table, Supabase tries to apply it.   In our case, we integrate with Lovable which generated migration files whose timestamps differ from the timestamps recorded in our production database (although the SQL has already been applied). Initially, Lovable was creating timestamps in UTC, and Supabase in another time zone but with different seconds. Currently, Supabase creates timestamps in UTC as well but the issue with the different seconds still persists (it is as if Supabase registers the time after successfully executing the sql, although some records seem to be having a timestamp with seconds before the migration file seconds from the name). Because the timestamps don’t match, running migrations against prod attempts to re-apply every file as if none were applied, which can cause duplicate/invalid operations.  

To Reproduce

 

1. Connect a Supabase project to Lovable and ask for an operation related to database changes
2. Check the generated migration file name
3. Check the version value in the migrations table  

Expected behavior

 

• Timestamps of migration files generated from Lovable should match the timestamps Supabase writes to its migrations table which is considered a source of truth.  

---

  Current impact: With mismatched timestamps between files and the production version values, any migration workflow will try to re-apply most/all migrations, risking failures or inconsistent state.   Another related issue: In our case we also have migration files which were partially executed in Lovable (hence in the migrations folder) but due to the failure they were not written in the Supabase migrations table.   Questions: Is that a problem related to Lovable only, Supabase Lovable integration, or Supabase only?

[Vansh5632]

this is the issue related to the supbase/cli repo the best way to resolve this is to replace time_stamp based matching to the uuid based matching creating a new issue there and linking this there

[jimstenoo]

had the same issue here,

solved it by mutating the timestamps in the migration table to the timestamps from the files in the repo

[JoeJoe1313]

@Vansh5632 @saltcod Could you please share any updates on this? Are you planning on fixing this issue in the near future? We have a workflow in which a solution to constantly manually fix the timestamps is not a feasible. Thank you!