To better secure your Supabase server instances, we will be removing superuser access from the dashboard SQL Editor over the next 30 days. Existing projects with tables, functions, or other Postgres entities created via the dashboard SQL Editor require a one time migration to be run. This migration should take less than 10 seconds to run but since it modifies your existing schema, we will be rolling out this change over a buffer period to minimise breakages.
During the opt-in period, a notification will be delivered to all affected Supabase projects. The notification contains instructions to manually apply the migration. If you have separate staging and production Supabase projects, apply it on the staging project first to verify everything is working as expected.
If you only have one Supabase project, try to avoid hours of high application traffic when applying the migration to minimise potential downtime. If you notice elevated error rates or other unusual activities after migrating, follow the rollback instructions to revert the change. Both apply now and rollback actions are idempotent. If you encounter any problems during migration or rollback, please contact [email protected] for further assistance.
For paused projects, applying now will schedule the migration script to run the next time your project is restored. We suggest that you restore your project immediately to verify that everything works or rollback if necessary. If you project is in any other states, please contact [email protected] to bring it to an active healthy state before continuing with the migration.
After successfully applying the migration, all entities you have created from the dashboard's SQL Editor will be owned by a temporary role. These entities are currently owned by supabase_admin role by default. You can check the current owner of all your schemas using the query below.
_10select *, nspowner::regrole::name from pg_namespace;
New entities created via the SQL Editor will also be owned by this temporary role. Since the temporary role is not a superuser, there are some restrictions with using the SQL Editor after migrating. If you are unsure whether those restrictions affect your project, please contact [email protected] for assistance.
After the opt-in period, you will receive another notification to drop the temporary role and reassign all entities owned by the temporary role to postgres role. The SQL Editor will also default to using postgres role. New projects created after 5 Nov will also default to using the postgres role. Since this change is irreversible, it is crucial that you run the migration during the opt-in period to verify that your project continues to work.
For any projects not migrated after 5 Nov deadline, we will run the migration on your behalf to reassign all entities to postgres role. No temporary role can be used for rollback. If you notice any breakages then, please do not hesitate to contact [email protected].
After revoking superuser access, you will not be able to perform the following actions through the dashboard SQL Editor.
You will no longer be able to create, alter, or drop event triggers directly through SQL statements.
Event triggers can only be created by superusers and you will not be able to manage them after the migration. One exception is Postgres extensions. When toggling extensions, they can still create or drop event triggers as needed.
If you are currently using custom event triggers, please contact [email protected] to explain your use case. We will try our best to figure out an alternative for your project. Note that regular triggers are unaffected by the migration.
You will no longer be able to: create, alter, or drop tables, views, functions, triggers, sequences, and other entities in Supabase managed schemas, including extensions, graphql, realtime, and supabase_functions.
Supabase managed schemas are used to support platform features for all projects. Entities in these schemas are owned by supabase_admin role to prevent users from accidentally overriding them and breaking platform features. Unless explicitly granted, non-superuser roles cannot manage entities in Supabase managed schemas after the migration.
If you think modifying these schemas is necessary for your project, please contact [email protected] to explain your use case. We will try our best to accommodate your use case using alternative suggestions.
Entities in auth and storage schemas have been explicitly granted all permissions to postgres role. Therefore, you can still manage these schemas directly through SQL statements. If you have existing triggers created on these schemas, they will continue to work as well.
All user defined schemas and the public schema will be owned by postgres role after the migration. Therefore, you should be able to manage entities in those schemas directly through SQL statements. One exception is if you have manually changed the owner of specific schemas before. In that case, you can either reassign their owner to postgres role manually or leave them untouched. Please reach out to [email protected] if you are unsure what to do.
You will no longer be able to create or drop RLS policies on entities in Supabase managed schemas.
RLS policies can only be created or dropped by entity owners or superusers. After the migration, you canât manage RLS policies in Supabase managed schemas through the SQL Editor. If you need to expose certain tables in realtime schema to anon or authenticated users, one way is to create a view in the public schema using the postgres role.
RLS policies in auth, storage, public, and all user defined schemas can still be managed directly through SQL statements. Unless you have policies that check for supabase_admin role, all existing RLS policies should be unaffected by the migration.
You will no longer be able to alter role attributes of replication, superuser, and reserved roles directly through the SQL Editor.
Only superuser roles can alter attributes of other superuser and replication roles. Reserved roles include anon, authenticated, postgres, service_role, etc. After the migration, you will not be able to change attributes of these roles directly through SQL statements. You can still alter attributes of other roles created by yourself, except to elevate those roles to superuser or replication.
Some common attributes that canât be changed include password, login, and bypassrls. Here are some known workarounds:
- To change your
postgres role password, you can do it via dashboard settings page.
- If you need to run one-off scripts that bypass RLS, you can use the provided service key.
- If you are pushing schema migrations from CLI, superuser privilege is no longer required as all entities are owned by
postgres role after the migration.
- Migrating between projects no longer requires superuser privilege.
A number of users reported the following error accessing the dashboard restoring a paused project.
_10Error: [500] failed to get pg.tables: password authentication failed for user "postgres_temporary_object_holder"
It is due to a bug in the restore script that we have since fixed. If you are still experiencing this issue, you may pause and restore the project again to fix it manually. If that fails, please don't hesitate to contact [email protected].
We will be adding additional privileges to the postgres role to do the following actions, which otherwise can only be done by a superuser:
- manage the
bypassrls role attribute
- set the
session_replication_role runtime config
- TimescaleDB extension fails to toggle (we can enable manually via support)
- Custom security definer functions will run as non-superuser (only affects extensions schemas owned by supabase_admin)
