Security Patch Notice#

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.

Opt-in Period: 5 Oct - 5 Nov#

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 support@supabase.io 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 support@supabase.io 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.

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 support@supabase.io for assistance.

After 5 Nov#

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 support@supabase.io.

Restricted Features#

After revoking superuser access, you will not be able to perform the following actions through the dashboard SQL Editor.

Managing Event Triggers#

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 support@supabase.io 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.

Restricted use of Supabase schemas#

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 support@supabase.io 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 support@supabase.io if you are unsure what to do.

Managing RLS Policies on Supabase schemas#

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.

Restricted use of Role Attributes#

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:

1. To change your postgres role password, you can do it via dashboard settings page.
2. If you need to run one-off scripts that bypass RLS, you can use the provided service key.
3. 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.
4. Migrating between projects no longer requires superuser privilege.

Update 26/10/22#

A number of users reported the following error accessing the dashboard restoring a paused project.

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 support@supabase.io.

Update 03/11/22#

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

Update 28/12/22#

• 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)

Supabase June Alpha Updates#

This is also available as a full blog post with videos.

We're now 4 months into building Supabase, which means another major update. Here's a few things we think you'll love in this release.

View relational data#

We're sometimes asked how we will make Postgres as simple as Firebase, since Postgres is a relational database. This month we're making our first steps to prove that relational databases can be even easier to use than document stores. We're releasing an excel-like editing interface which can drill down into your relational data.

Manage JSON data#

Postgres is an amazing database, giving the flexibility of a document store with the power of a RDBMS. If you use JSON data in Postgres, then we want to make that easy too. Supabase detects when your column is JSON or JSONB, and provides an easy way to edit and view your data. More improvements coming soon for this feature!

Choose your region#

If you noticed a bit of latency on Supabase, it's because your projects were previously set up in Singapore. It was always our intention that you'd be able to choose your database region, and this month we've delivered it. In the next releases we'll even allow you to go multi-region, instantly replicating your database close to your customers.

Backups#

A guiding principle at Supabase is zero lock-in. So this month we are exposing your daily database backups on the dashboard, giving you a simple way to migrate off Supabase. We have a lot more to build in this space (WAL-G!), so watch this space.