New updates and product improvements
Previously, it was possible to directly insert/update rows on the pg_cron extension's cron.job table. This bypasses security checks that would've been asserted when jobs are scheduled/modified via pg_cron functions.
You can see how to schedule/modify cron jobs using the examples in our docs.
Nov 27, 2023
PR: https://github.com/supabase/supabase/pull/19126 Link: https://supabase.com/dashboard/project/_/database/backups/scheduled
PR: https://github.com/supabase/supabase/pull/19012 Link: https://supabase.com/dashboard/org/_/team
PR: https://github.com/supabase/supabase/pull/19095 Link: https://supabase.com/dashboard/support/new
PR: https://github.com/supabase/supabase/pull/19062 Link: https://supabase.com/dashboard/project/_/storage/buckets
PR: https://github.com/supabase/supabase/pull/17341 Link: https://supabase.com/dashboard/project/_/sql/new
Shout out to @tranhoangvuit for this one! 🙏 PR: https://github.com/supabase/supabase/pull/19127 Link: https://supabase.com/dashboard/project/_/editor
LinkedIn has modified the required scopes for their API and OAuth Applications created prior to 1st Aug 2023 do not contain the appropriate scopes. This could cause errors when attempting to sign in with OAuth via LinkedIn. If you have LinkedIn provider enabled on your project a follow up notification will be sent to your email as you could potentially have a LinkedIn OAuth application created before 1st Aug 2023 and be affected. As we don't have access to LinkedIn OAuth configuration we cannot tell with certainty when your OAuth application was created and have to reach out to all users with LinkedIn enabled.
To adjust to this change, we have introduced a new LinkedIn (OIDC) provider which contains the new required scopes and we have deprecated the existing LinkedIn provider.
If you are using a LinkedIn OAuth Application created before 1st August 2023 we ask that you create a new LinkedIn application and migrate your Dashboard credentials from the deprecated LinkedIn provider to the new LinkedIn (OIDC) provider as shown in the screenshot below. Please do so before 4th Jan 2024 as we will be removing the provider from the dashboard then.
Edge Functions has some predefined secrets: SUPABASE_DB_URL, SUPABASE_ANON_KEY, SUPABASE_SERVICE_ROLE_KEY. Previously, if you reset your DB password or JWT secret, these secrets will become stale. Now, these changes should be propagated into Edge Functions secrets. This fixes https://github.com/supabase/supabase/issues/12415.
If you've previously had this issue, you can reset your DB password using the old value to avoid downtime for your app. If you're resetting the JWT secret, you need to update your app to use the new API keys, which incurs some downtime.
Realtime runs migrations for tables under the realtime schema when it connects to databases. Sometimes this fails. These changes handle Realtime migration failures better.
https://github.com/supabase/realtime/compare/v2.25.22...v2.25.27
🙏 @filipecabaco
Nov 9, 2023
Support for column encryption in the table editor has been removed. You can still use it, but you must use SQL. Your data is already encrypted-at-rest, so this is an advanced feature that should be used sparingly.
Previously, the Table Editor in the Supabase dashboard supported encrypting newly created columns using pgsodium’s Transparent Column Encryption (TCE).
While this makes it easy to use, we found that the easiness has led to a lot of “mis-use” of Encryption. We’ve decided to remove it from the UI for now because TCE has a few sharp edges and the dashboard makes it too easy to encrypt columns without considering trade-offs.
This mis-use led to multiple users frequently running into unrecoverable issues with encryption. A non-exhaustive list of issues which we observed users running into when using TCE through the dashboard includes the following:
pg_sodium to make the view a security invoker.As of now, you can use TCE in SQL by following the pg_sodium documentation so users who already are using TCE can continue doing so via the SQL editor on the dashboard, while new users will have to learn the nuts and bolts of what they are doing before trying to use the feature.
If you use Deno Postgres or other Postgres clients to connect to your database instance from a Supabase Edge Function, those connections are now secured with SSL. You don't need to add any extra configurations to your client setup.
More details: https://supabase.com/docs/guides/functions/connect-to-postgres#ssl-connections
Nov 2, 2023
Databases larger than 100GB are being transitioned to using physical backups for their daily backups.
Physical backups are more performant, have lower impact on the db, and avoid holding locks for long periods of time. Restores continue to work as expected, but backups taken using this method can no longer be downloaded from the dashboard.
Over the next few months, we'll be introducing functionality to restore to a separate, new database, allowing for the perusal of the backed up data without disruption to the original project.
Please refer to https://supabase.com/docs/guides/platform/backups#daily-backups-process for additional details.
Oct 14, 2023
Postgres 12 is deprecated as of 14th October 2023 and support for it will be fully removed on 27th November 2023.
Postgres 15 comes with numerous features, bug fixes and performance improvements. Check out the announcement blog posts to find out what each version introduces.
You will receive three notifications via email before 27th November notifying you about the deprecation of Postgres 12 and deprecation of IPv4 and PGBouncer.
Sep 29, 2023
With IPv4 addresses becoming increasingly scarce and cloud providers starting to charge for it, we won’t be assigning IPv4 addresses to Supabase projects from January 15th 2024. db.projectref.supabase.co will start resolving to a IPv6 address instead. If you plan on connecting to your database directly, you must ensure that your network can communicate over IPv6. Supavisor will continue to return IPv4 addresses, so you can update your applications to connect to Supavisor instead.
There will be a few minutes of downtime during this migration.
We recently announced Supavisor, our new connection pooler. Supavisor is a direct replacement for PgBouncer. Using our own pooler is going to let us do things like load balancing queries across read replicas, query results caching, and a lot more.
Supavisor is now enabled for all projects created on or after Wednesday September 27th 2023. All existing projects will have Supavisor enabled by October 15th 2023.
Supavisor does not currently support Network Restrictions. Network restrictions support will be enabled from 24th January 2024. If you are blocked on the migration because of this, please reach out to support and we will extend the deadline for your project.
You don’t need to change anything in your application, except for the URL. The pooler connection string is available in the database settings in your dashboard.
For example, if you use PgBouncer to connect:
_10import { drizzle } from 'drizzle-orm/postgres-js'_10import postgres from 'postgres'_10import { users } from './schema'_10_10// probably an env var_10const connectionString = 'postgres://user:[YOUR-PASSWORD]@db.[YOUR-PROJECT-ID].supabase.co:6543/postgres'_10const client = postgres(connectionString)_10const db = drizzle(client);_10_10const allUsers = await db.select().from(users);
you just need to update the connection string to:
_10import { drizzle } from 'drizzle-orm/postgres-js'_10import postgres from 'postgres'_10import { users } from './schema'_10_10// probably an env var, get the exact connection string from the database settings page_10const connectionString = 'postgres://[db-user]:[db-password]@aws-0-[aws-region].pooler.supabase.com:6543/[db-name]?options=reference%3D[project-ref]'_10const client = postgres(connectionString)_10const db = drizzle(client);_10_10const allUsers = await db.select().from(users);
PgBouncer will be available to use along side Supavisor until January 31st 2024.
The full timeline is:
db.projectref.supabase.co) will start resolving to IPv6 addresses. PgBouncer will be removed. Projects will be migrated over starting this day. No changes are required if your network supports communicating via IPv6. If it doesn't, update your applications to use Supavisor which will continue to return IPv4 addresses.You will receive deprecation notices throughout November, December, and January.
For projects which only use the database REST API provided by PostgREST (via supabase-js) there is no action needed.
projectref.supabase.co will continue to return IPv4 addresses. Only the database domain db.projectref.supabase.co will return a IPv6 address.
Check if you are able to request your IPv6 address via curl -6 https://ifconfig.co/ip
If you have issues with Supavisor please contact support!
You can purchase the IPv4 addon for 4$/project in the project add-on page here. PGBouncer will still be removed for users with the IPv4 add-on.
While we are providing the ability to use PgBouncer or Supavisor during this migration you cannot use both at the same time. With the default configuration using both will exhaust your database connections because they both will try and spin up a connection pool.
The solution is to temporarily increase your databases connection limit with a custom Postgres config to accommodate both connection pools.
_10supabase --experimental --project-ref <project-ref> postgres-config update --config max_connections=120
If the URL you use to connect to your Supabase Database looks like this, you're using the API, and no changes are necessary:
https://[YOUR-PROJECT-ID].supabase.co
If the URL you use to connect looks like either of these options, you're already using Supavisor, and no further changes are necessary:
postgres://[db-user]:[db-password]@aws-0-[aws-region].pooler.supabase.com:6543/[db-name]?options=reference%3D[project-ref] or postgres://[db-user].[project-ref]:[db-password]@aws-0-[aws-region].pooler.supabase.com:6543/[db-name]
If the URL you use to connect looks like this, you are using pgBouncer, and you need to upgrade (notice port 6543):
postgresql://[db-user]:[db-password]@db.[project-ref]supabase.co:6543/[db-name]
If the URL you use to connect looks like this, you are connecting directly, and will either need to be able to connect via IPv6, OR you will need to update to the Supavisor URL:
postgresql://[db-user]:[db-password]@db.[project-ref].supabase.co:5432/[db-name]
In the database settings page, the label when connection pooling is disabled, reads Will resolve to IPv6 if your project has not been migrated. If your project has been migrated to IPv6, it reads `Resolves to IPv6'.
The error thrown will depend on how you are connecting to the database. Here are some examples of error messages you might see
(dial tcp [2001:db8:3333:4444:5555:6666:7777:8888]:5432: connect: no route to host)connect to db.example.supabase.co (2001:db8:3333:4444:5555:6666:7777:8888) port 5432 (tcp) failed: Network is unreachablecould not translate host name "db.example.supabase.co" to address: nodename nor servname provided, or not knownENETUNREACH 2001:db8:3333:4444:5555:6666:7777:8888Error: P1001: Can't reach database server at db.example.supabase.co:5432Note that these errors may manifest in cases other than your client network not supporting IPv6, but if you run into these errors after your project was migrated, it is likely that it is due to IPv6 support.
The database settings page does not show PgBouncer connection settings. If you see a warning label called PgBouncer pending removal, it means that PgBouncer has not been removed from your project. If you see no such label, PgBouncer has already been removed from your project.
Prepared statements are supported with session mode. You can change your pool mode to session in your dashboard.
You can also use a session mode pool with your Supavisor pooler url and port 5432 (vs 6543). If you need to run something using prepared statements while your production application uses transaction mode you can use this port to do that.
Initial support for prepared statements with transaction mode landed but some bugs were found and should be fixed shortly.
If you are using Prisma, please check out our updated Prisma Guide for instructions on how to configure your connections for both querying and migrations.
The environment variables POSTGRES_URL and POSTGRES_PRISMA_URL point to Supavisor and POSTGRES_URL_NON_POOLING points to Supavisor in session mode. Redeploy your Vercel application to pick up the latest environment variables. This is required since Vercel does not support IPv6.
Enable the IPv4 add-on. Set the direct connection url as a environment variable not managed by the Supabase integration. You can now use the environment variable in your application.
If you are using a version before 1.136.3, please upgrade to a later version of the CLI and run supabase link. If you haven’t run supabase link since 1st January 2024, please run it again after upgrading. This will enable the CLI to communicate to the database from IPv4 only environments because the communication happens via Supavisor. This change is required if you are using from the CLI from an environment without IPv6 support, like Github actions or possibly from your home network.
You will need to add Pooling=false to your Supavisor connection string.
We are in the midst of transitioning all projects to IPv6. As part of this process, If your project is still being assigned an IPv4 address then pg_upgrade will be temporarily disabled for your project until the transition is completed.
Aug 31, 2023
We’re fixing the billing system at Supabase - moving from “project-based” to “organization-based”. We should have started with this model, but I wasn’t wise enough to know that when we started. We need to make these changes to roll out Preview Environments / Branching. It also includes:
See all changes in the blog post
First, and most importantly - there is only one change that affects the free plan, and that is a good one for you: you now an extra 1GB of egress.
| Usage Item | Old plan (per project) | New plan (org based) |
|---|---|---|
| Egress | 4GB - (2GB Database + 2GB Storage) | 5GB across Database + Storage |
| Database Space | 500MB | 500MB |
| Storage Space | 1GB | 1GB |
| Monthly Active Users | 50K | 50K |
| Edge Function Invocations | 500K | 500K |
| Edge Function Count | 10 | 10 |
| Realtime Message Count | 2 million | 2 million |
| Realtime Peak Connections | 200 | 200 |
| 2 free projects | 2 free orgs (1 free database per org) |
On top of an extra 1GB of egress for free, now that egress is unified across your org it means that if you aren’t using Supabase Storage, you get even more Database Egress (5GB instead of 2GB previously)
If you are currently running 2 free projects however, this does require some work from you. Because we are now working on an Org-level, instead of Projects, you will need to:
This should be done before the end of October, but don’t worry - we’ll give you frequent comms and clear instructions once the change has been rolled out (4th Sept).
We’ve made a lot of improvements to the billing system. Read the full announcement on our blog or dive into the related docs for more details.
This is a major change, and we've tried to design it in a way that's cheaper for everyone. If your bill has increased as a result of this change, that's not our intention. Please submit a Support ticket on the dashboard and we'll figure out a solution.
We welcome any questions/feedback about this change, but please keep this discussion focused only on this change! It's important for those who want to learn more or are confused. If you have something off-topic, please open a new discussion or join an existing discussion
Oct 4, 2022
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 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.
_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 support@supabase.io 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 support@supabase.io.
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 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.
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.
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:
postgres role password, you can do it via dashboard settings page.postgres role after the migration.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 support@supabase.io.
We will be adding additional privileges to the postgres role to do the following actions, which otherwise can only be done by a superuser:
bypassrls role attributesession_replication_role runtime config