Policies for tables are not added in migration on `db pull`

[xidsyed]

Describe the bug

• perform supabase db pull on a fresh local instance from a fresh remote instane with one dummy posts table with few dummy rows . and rls policies. also one storage bucket posts with one rls policy on storage.objects table.

• migration file gets created on both sides.

• supabase db reset to apply migration and seed data

• everything shows up perfectly. EXCEPT THE POLICY FOR STORAGE.OBJECTS

Supabase CLI 2.31.8

should i not rely on the supabase db diff command to make migrations for me?

[xidsyed]

$ supa db diff --local
Creating shadow database...
Initialising schema...
Seeding globals from roles.sql...
Applying migration 20250725101210_remote_schema.sql...
Connecting to local database...
Diffing schemas: extensions,public
Finished supabase db diff on branch main.

No schema changes found

I ended up adding the policy manually via the gui. and then i tried to diff it locally to see if it would pickup on the change and create a new migration. It didn't.

I guess it's a good thing that its consistently wrong both times.

[longtimedeveloper]

@xidsyed I started using Supabase Declarative database schemas.

Now, I don't need to pull from the database, instead, I only create migrations based on supabase/schemas folder .sql files. This feature provides a single source of truth for your database. I have been using this for over 3 weeks with zero issues.

I hope this helps.

[xidsyed]

@longtimedeveloper
appreciate the comment. is your current project complex enough. have u made several changes using the new declarative schema.

on the supabase website they claim that the declarative schema is still experimental. and they list out many usecases where the declarative schema fails as well.

ill stick to diffs and migrations since that's been out for a while now.

but apparently those aren't good enough either... I hope they stick to one tool and make it robust

[longtimedeveloper]

@xidsyed Yes I have made migrations after the initial push.

I have not run into any of the limited edge cases they call out.

If I need a policy change, I would drop the policy and then create it again in the supabase/schemas/my_sql_file.sql This avoids the lack of alter policy support.

I highly recommend watching this Supabase video How Supabase Simplifies Your Database Management with Declarative Schema. They fully acknowledge the pain of just using migrations.

IMO: Having a single source of truth for you schema is so much better than the endless schema changes. Also when developing, you can reset your database and push a fresh initial migration.

When required, this is how I reset my database, make an initial migration, and push to the local server.

supabase db reset --local
supabase db diff -f initial
supabase db push --local

[xidsyed]

so you've moved away from the migration files concept all together i gather? you only always use your initial migration and as for rolling back / version control you use git version control.

When required, this is how I reset my database, make an initial migration, and push to the local server.
supabase db reset --local
supabase db diff -f initial
supabase db push --local

i ddint understand this. is this your alternative supabase db reset because you're not using migration files. i guess im still a bit skeptical that all the db changes can be sufficiently represented purely using the declaratice schema. migrations files seem more robust

[longtimedeveloper]

No, I use the migrations. After my initial migration is created, I edit the source files in the /schemas folder as required, then run

supabase db diff -f <migration name>
supabase db push --local

The only time I use the above previous three commands is when it is required.

This is a very simple and very productive workflow, so much better than just using migration files alone as was explained in the YouTube video.