Missing grants in generated migration generated with version 2.33.0 and above (db pull --linked)

[ex0ns]

Describe the bug

When generating database migrations, Supabase CLI 2.33.0 output's is very different from previous version:

• does not include GRANT on the newly created table
• revoke existing privilege (this is probably wrong and dangerous !)
• re-create all functions in our database

To Reproduce

supabase db pull -s public,private --linked

Expected behavior
As of 2.32.0, the generated migration was:

create table "public"."sample_table" (
 "id" bigint generated by default as identity not null,
 "company_id" bigint not null,
 "name" text not null,
 "created_at" timestamp with time zone not null default now()
);

alter table "public"."sample_table" enable row level security;

-- INDEX CREATION
CREATE UNIQUE INDEX sample_table_pkey ON public.sample_table USING btree (id);

-- CONSTRAINTS
alter table "public"."sample_table" add constraint "sample_table_pkey" PRIMARY KEY using index "sample_table_pkey";
alter table "public"."sample_table" add constraint "sample_table_company_id_fkey" FOREIGN KEY (company_id) REFERENCES companies(id) ON DELETE CASCADE not valid;
alter table "public"."sample_table" validate constraint "sample_table_company_id_fkey";

-- PERMISSION GRANTS (✅ Present in 2.32.0)
grant delete on table "public"."sample_table" to "anon";
grant insert on table "public"."sample_table" to "anon";
grant references on table "public"."sample_table" to "anon";
grant select on table "public"."sample_table" to "anon";
grant trigger on table "public"."sample_table" to "anon";
grant truncate on table "public"."sample_table" to "anon";
grant update on table "public"."sample_table" to "anon";

grant delete on table "public"."sample_table" to "authenticated";
grant insert on table "public"."sample_table" to "authenticated";
grant references on table "public"."sample_table" to "authenticated";
grant select on table "public"."sample_table" to "authenticated";
grant trigger on table "public"."sample_table" to "authenticated";
grant truncate on table "public"."sample_table" to "authenticated";
grant update on table "public"."sample_table" to "authenticated";

grant delete on table "public"."sample_table" to "service_role";
grant insert on table "public"."sample_table" to "service_role";
grant references on table "public"."sample_table" to "service_role";
grant select on table "public"."sample_table" to "service_role";
grant trigger on table "public"."sample_table" to "service_role";
grant truncate on table "public"."sample_table" to "service_role";
grant update on table "public"."sample_table" to "service_role";

-- RLS POLICIES
create policy "Users can access sample table"
on "public"."sample_table"
as permissive
for all
to authenticated
using ((( SELECT (((auth.jwt() -> 'app_metadata'::text) ->> 'user_role'::text) = 'admin'::text)) AND (( SELECT private.get_company_for_user() AS get_company_for_user) = company_id)))
with check ((( SELECT (((auth.jwt() -> 'app_metadata'::text) ->> 'user_role'::text) = 'admin'::text)) AND (( SELECT private.get_company_for_user() AS get_company_for_user) = company_id)));

-- TRIGGERS
CREATE TRIGGER handle_updated_at BEFORE UPDATE ON public.sample_table FOR EACH ROW EXECUTE FUNCTION moddatetime('updated_at');

Current results

-- ❌ REVOKES existing permissions (this part is unexpected)
revoke delete on table "public"."existing_table_1" from "anon";
revoke insert on table "public"."existing_table_1" from "anon";
-- ... (many more revoke statements for existing tables)

revoke delete on table "public"."existing_table_2" from "authenticated";
revoke insert on table "public"."existing_table_2" from "authenticated";
-- ... (many more revoke statements for existing tables)

-- NEW TABLE CREATION (same as 2.32.0)
create table "public"."sample_table" (
 "id" bigint generated by default as identity not null,
 "company_id" bigint not null,
 "name" text not null,
 "created_at" timestamp with time zone not null default now()
);

alter table "public"."sample_table" enable row level security;

CREATE UNIQUE INDEX sample_table_pkey ON public.sample_table USING btree (id);
alter table "public"."sample_table" add constraint "sample_table_pkey" PRIMARY KEY using index "sample_table_pkey";
alter table "public"."sample_table" add constraint "sample_table_company_id_fkey" FOREIGN KEY (company_id) REFERENCES companies(id) ON DELETE CASCADE not valid;
alter table "public"."sample_table" validate constraint "sample_table_company_id_fkey";

-- ❌ MISSING: No GRANT statements for the new table

-- RLS POLICIES (present)
create policy "Users can access sample table"
on "public"."sample_table"
as permissive
for all
to authenticated
using ((( SELECT (((auth.jwt() -> 'app_metadata'::text) ->> 'user_role'::text) = 'admin'::text)) AND (( SELECT private.get_company_for_user() AS get_company_for_user) = company_id)))
with check ((( SELECT (((auth.jwt() -> 'app_metadata'::text) ->> 'user_role'::text) = 'admin'::text)) AND (( SELECT private.get_company_for_user() AS get_company_for_user) = company_id)));

-- TRIGGERS (present)
CREATE TRIGGER handle_updated_at BEFORE UPDATE ON public.sample_table FOR EACH ROW EXECUTE FUNCTION moddatetime('updated_at');

-- ALL FUNCTIONS RECREATED
-- Note: 2.33.0 recreates all existing functions, which seems unnecessary
-- CREATE OR REPLACE FUNCTION ... (many functions recreated)

System information

• Version of OS: OSX 15.6
• Version of CLI: 2.33.0
• Versions of services:

 SERVICE IMAGE | LOCAL | LINKED 
 ------------------------|------------------------|-----------
 supabase/postgres | 15.1.1.25 | 15.1.1.25 
 supabase/gotrue | v2.178.0 | v2.178.0 
 postgrest/postgrest | v12.0.2 | v12.0.2 
 supabase/realtime | v2.41.3 | - 
 supabase/storage-api | v1.25.9 | - 
 supabase/edge-runtime | v1.68.0 | - 
 supabase/studio | 2025.07.21-sha-88dca02 | - 
 supabase/postgres-meta | v0.91.1 | - 
 supabase/logflare | 1.14.2 | - 
 supabase/supavisor | 2.5.7 | - 

Additional context
I also tried with the latest version of the CLI and it's the same as with 2.33.0. I used this version to narrow down the problem but I can't find anything in v2.32.0...v2.33.0 that could explain that difference.

I also tested on 2.38.2 and it's the same

[ex0ns]

Any news on that ? I wanted to investigate, I'm struggling to find the root cause and this is prevent is from upgrading to the latest version of the CLI (which has many fixes related to declarative schemas)

[Joaquin-Mendoza-Eurekant]

same problem

[alexandercad]

I have this issue also. Im sticking to v2.32.0 for now. Not sustainable in the long run though.

[PatoSala]

I have a similar problem but related to the storage schema. #4107
Update: I tried creating another local instance and now the revoke statements where also generated on the auth table.

[Nishchit14]

I am facing this issue. I just run npx supabase db pull and supabase has created 2000+ line of migration with revoke queries. This is a huge concern on stability. I am unable to move forward without resolving this issue.

The CLI version is 2.39.2.

revoke update on table "stripe"."coupons" from "service_role";

revoke delete on table "stripe"."coupons" from "supabase_admin";

revoke insert on table "stripe"."coupons" from "supabase_admin";

revoke references on table "stripe"."coupons" from "supabase_admin";

revoke select on table "stripe"."coupons" from "supabase_admin";

revoke trigger on table "stripe"."coupons" from "supabase_admin";

revoke truncate on table "stripe"."coupons" from "supabase_admin";

revoke update on table "stripe"."coupons" from "supabase_admin";

revoke delete on table "stripe"."subscriptions" from "service_role";

revoke insert on table "stripe"."subscriptions" from "service_role";

revoke references on table "stripe"."subscriptions" from "service_role";

revoke select on table "stripe"."subscriptions" from "service_role";

revoke trigger on table "stripe"."subscriptions" from "service_role";

revoke truncate on table "stripe"."subscriptions" from "service_role";

revoke update on table "stripe"."subscriptions" from "service_role";

revoke delete on table "stripe"."subscriptions" from "supabase_admin";

revoke insert on table "stripe"."subscriptions" from "supabase_admin";

revoke references on table "stripe"."subscriptions" from "supabase_admin";

revoke select on table "stripe"."subscriptions" from "supabase_admin";

revoke trigger on table "stripe"."subscriptions" from "supabase_admin";

revoke truncate on table "stripe"."subscriptions" from "supabase_admin";

revoke update on table "stripe"."subscriptions" from "supabase_admin";

[PatoSala]

I am facing this issue. I just run npx supabase db pull and supabase has created 2000+ line of migration with revoke queries. This is a huge concern on stability. I am unable to move forward without resolving this issue.

The CLI version is 2.39.2.

revoke update on table "stripe"."coupons" from "service_role";

revoke delete on table "stripe"."coupons" from "supabase_admin";

revoke insert on table "stripe"."coupons" from "supabase_admin";

revoke references on table "stripe"."coupons" from "supabase_admin";

revoke select on table "stripe"."coupons" from "supabase_admin";

revoke trigger on table "stripe"."coupons" from "supabase_admin";

revoke truncate on table "stripe"."coupons" from "supabase_admin";

revoke update on table "stripe"."coupons" from "supabase_admin";

revoke delete on table "stripe"."subscriptions" from "service_role";

revoke insert on table "stripe"."subscriptions" from "service_role";

revoke references on table "stripe"."subscriptions" from "service_role";

revoke select on table "stripe"."subscriptions" from "service_role";

revoke trigger on table "stripe"."subscriptions" from "service_role";

revoke truncate on table "stripe"."subscriptions" from "service_role";

revoke update on table "stripe"."subscriptions" from "service_role";

revoke delete on table "stripe"."subscriptions" from "supabase_admin";

revoke insert on table "stripe"."subscriptions" from "supabase_admin";

revoke references on table "stripe"."subscriptions" from "supabase_admin";

revoke select on table "stripe"."subscriptions" from "supabase_admin";

revoke trigger on table "stripe"."subscriptions" from "supabase_admin";

revoke truncate on table "stripe"."subscriptions" from "supabase_admin";

revoke update on table "stripe"."subscriptions" from "supabase_admin";

I have the same issue for auth and storage schema. I created a GitHub issue and discord thread for this if you are interested.
#4107

https://discord.com/channels/839993398554656828/1414243526438424667

[mmohamedgit]

Same problem for me too

[Nishchit14]

@PatoSala I am now seriously thinking to move from Supabase.

[PatoSala]

@Nishchit14 the best we can do is start opening issues about this or giving support to the already created ones so the Supabase team can easily see that this is a problem the community is facing.

[Nishchit14]

Already created the support ticket. No respose yet. This is second time for me. Last year I had created ticket but no resolution from their team. The person was asking again and again same question in support being novice. I had really a worst experince with Supabase.

[PatoSala]

Any updates on this? @ex0ns

[ex0ns]

No, unfortunately I did not get the time to investigate that further, sticking with the old cli version for now

[PatoSala]

No, unfortunately I did not get the time to investigate that further, sticking with the old cli version for now

Which version are you using? Does it create unwanted permission revokes?

[ex0ns]

I'm using v2.31.8 when I need a db pull --linked