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.