Si le SQL Editor Supabase vous repond 42501: permission denied to change default privileges sur une commande ALTER DEFAULT PRIVILEGES, ce n'est pas forcement que vous avez mal configure votre projet. Dans beaucoup de cas, c'est simplement PostgreSQL qui applique sa regle normale sur un role que vous ne possedez pas directement.
Dit autrement : etre admin dans le dashboard Supabase ne veut pas dire etre proprietaire technique de tous les roles Postgres geres par la plateforme.
Pourquoi cette erreur apparait
ALTER DEFAULT PRIVILEGES ne modifie pas une table precise. Cette commande change les privileges qui seront appliques plus tard aux objets crees par un role donne.
PostgreSQL est strict sur ce point. D'apres sa documentation, vous pouvez modifier :
- vos propres default privileges
- ou ceux d'un role dont vous etes membre
En revanche, vous ne pouvez pas changer librement les default privileges d'un role gere par un autre acteur.
C'est exactement ce qui se passe souvent avec supabase_admin dans Supabase.
Le malentendu classique
Le raisonnement ressemble a ca :
- je suis connecte comme admin dans Supabase
- donc je devrais pouvoir lancer n'importe quel SQL d'administration
- donc si
ALTER DEFAULT PRIVILEGESechoue, il y a un probleme de droits
Le point faible de ce raisonnement, c'est qu'il melange deux niveaux differents :
- le role d'administration du dashboard Supabase
- les roles Postgres et leur propriete reelle dans la base
Supabase vous donne beaucoup de controle, mais pas necessairement la maitrise totale des roles systeme ou des roles geres par la plateforme.
Pourquoi supabase_admin coince souvent
Dans un projet Supabase, certains comportements de securite et d'infrastructure reposent sur des roles internes ou geres par la plateforme. Vous pouvez voir leur existence, subir leurs effets, et parfois lire leurs default privileges, sans pour autant avoir le droit de les modifier depuis le SQL Editor.
C'est pour cela qu'une commande comme celle-ci peut echouer :
alter default privileges for role supabase_admin in schema public
revoke select, insert, update, delete on tables from anon, authenticated, service_role;L'erreur n'indique pas forcement un mauvais compte. Elle indique surtout que le role courant n'a pas le droit de changer les defaults de supabase_admin.
Ce que cette erreur ne veut pas dire
Cette erreur ne veut pas dire :
- que votre projet est casse
- que vous n'etes pas vraiment admin dans Supabase
- que vos tables existantes sont inutilisables
- que vous devez absolument contourner le probleme pour avancer
Elle veut surtout dire que vous etes en train d'essayer de modifier un niveau de privileges plus profond que celui auquel le SQL Editor vous donne acces.
La bonne reaction pratique
La pire reaction consiste a passer du temps a essayer dix variantes de la meme commande jusqu'a tomber sur un contournement douteux.
La bonne reaction est beaucoup plus simple :
- verifier que l'option Automatically expose new tables reste desactivee dans
Integrations > Data API > Settings - creer les nouvelles tables via migrations SQL, pas uniquement via le Table Editor
- ajouter les
GRANTexplicites dans la migration de la table - corriger les tables creees par erreur au niveau de la table, pas au niveau des default privileges
En clair : si vous ne pouvez pas nettoyer supabase_admin globalement, travaillez proprement table par table. Pour un projet produit, c'est souvent suffisant.
Le rattrapage propre pour une table deja creee
Si une table a ete creee depuis le dashboard ou avec des defaults trop permissifs, vous pouvez la corriger explicitement :
revoke all on table public.your_table from anon, authenticated, service_role;grant select on table public.yourtable to anon; grant select, insert, update on table public.yourtable to authenticated; grant select, insert, update, delete on table public.yourtable to servicerole;
alter table public.your_table enable row level security; ```
Et si une sequence doit etre protegee aussi :
revoke all on sequence public.your_table_id_seq from anon, authenticated, service_role;Cette approche ne depend pas d'un acces special a supabase_admin. Elle corrige l'objet concret qui vous interesse.
Pourquoi cette methode est meilleure pour un vrai projet
Sur le terrain, ce que vous voulez n'est pas gagner un debat abstrait sur les roles systeme. Ce que vous voulez, c'est :
- que les nouvelles tables soient creees proprement
- que l'API n'expose pas plus que necessaire
- que l'equipe sache quoi faire a chaque nouvelle migration
- que la securite reste lisible six mois plus tard
Une politique de migration claire vaut beaucoup plus qu'une tentative de forcer un role gere par la plateforme.
Le point important sur PostgreSQL
Il y a un detail important dans la documentation PostgreSQL : les default privileges appliques a un nouvel objet dependent du role courant qui cree l'objet. Ils ne sont pas herites automatiquement depuis tous les roles dont on pourrait etre membre.
C'est une nuance importante, car elle explique pourquoi deux flux de creation de table peuvent se comporter differemment dans Supabase selon l'outil ou le role qui cree effectivement l'objet.
La vraie regle d'equipe a retenir
Pour eviter de retomber sur cette erreur, gardez cette regle :
- une table publique creee par migration doit recevoir ses
GRANTdans la meme migration - si la table doit etre exposee, on active aussi la RLS et on ajoute les policies
- on ne compte jamais sur un comportement automatique de la Data API pour des donnees importantes
Avec cette discipline, l'erreur 42501 devient surtout un rappel utile, pas un blocage produit.
Ce qu'il faut retenir
Si ALTER DEFAULT PRIVILEGES echoue sur supabase_admin dans Supabase, ce n'est pas une anomalie grave. C'est le resultat logique des regles de PostgreSQL appliquees a un role gere par la plateforme.
Le bon correctif n'est pas de s'acharner sur cette commande. Le bon correctif est de travailler au niveau des migrations et des tables reelles, avec des GRANT explicites, de la RLS, et un flux de schema propre.