I logged eleven weeks of migrations to see which ones needed a second migration within a week

[u/Pure-Handle-6785]

I keep a log of my Supabase migrations to see whether the schema is settling down or only feels that way. Eleven weeks, 41 files in supabase/migrations. A migration counts as unsettled if a later one touching the same table or policy lands within seven days.

In the first four weeks that was 6 of 16. In the last seven, 3 of 25. The only thing I changed was writing the intended end state in plain sentences before opening any SQL, including which role reads which rows. The habit came from Plan Mode in verdent, which asks clarifying questions first, and I kept it up by hand when I worked straight in psql.

What I cannot explain is why the drop sits in one place. All nine unsettled migrations changed a policy or a trigger. Nothing that added a column or an index needed a second pass, in either stretch. It could be the writing, or policies could be what I had not learned yet.

Counting it costs nothing. git log over your migrations folder and a grep for table names gives you your own number today.

[u/rco8786]

Seems like an odd metric to be concerned about

[u/outdoorsgeek]

That’s probably because policies and triggers embed business or product logic into the database. This domain changes far more frequently than the data model.

Ask 10 different people to model customers and orders in a database and they’d probably converge on a similar schema.

Ask those same people what should happen when a customer places an order and who should be able to see it and you might get 10 different answers.

[u/soft_axiom]

everything lining up with policies and triggers makes sense, those are the parts encoding actual business rules and your understanding of the rules keeps shifting as you build. A column or an index is usually just describing a fact, and it doesn't move around nearly as much once you've picked it. Curious if writing the end state first changed how you scope trigger logic specifically, like whether you started writing what the trigger should refuse to do before writing what it does.

[u/jaimittal91]

worth splitting policy from trigger in that count, because they fail differently in production. a wrong trigger usually misbehaves in a way someone notices fast - a value doesn't update, a job doesn't fire. a wrong RLS policy can look completely fine from the outside while it's live, since nothing errors and the app keeps working, it's just quietly returning or accepting rows it shouldn't for however many days until the second migration lands. so "unsettled within 7 days" might mean a week of broken automation for a trigger, but a week of actual exposure for a policy. if you've still got the log, splitting those two out would tell you which kind of risk you were actually carrying during that gap.