New updates and product improvements

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

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.


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.

How it was previously

Previously, the Table Editor in the Supabase dashboard supported encrypting newly created columns using pgsodium’s Transparent Column Encryption (TCE).


Why we’re changing it

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:

  • TCE is prone to inappropriate usage - we’ve seen users encrypting all kinds of stuff that does not need to be encrypted (e.g email address of sender/receivers). This incurs a performance penalty and results in a bad experience.
  • TCE makes migrating between projects (or local to hosted) a problem as you’d also have to copy the root encryption key separately, although this is nonetheless by design. Developers should be aware that “just works” and “advanced encryption” are very difficult goals to align.
  • Triggers (which are used by TCE) are executed in alphabetical order. When users add their own triggers on encrypted tables, they are frequently unaware if they are dealing with encrypted or unencrypted contents which has been a source of confusion.
  • Upserting into an encrypted column could produce doubly encrypted content.
  • Since TCE uses a view into an encrypted table, RLS rules that are applied on the underlying table do not apply to the views as views use the permissions of the creator rather than the query-er, leading to another source of confusion. There is a fix for this which is to add a security label to pg_sodium to make the view a security invoker.

If you want TCE, use SQL instead

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.

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 for additional details.

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.

Deprecation Timeline

  • 15th October: All users are notified via email about Postgres 12 Deprecation.
  • 27th October: Users can self serve upgrade to Postgres 15 from our dashboard. If you want to upgrade your database to Postgres 15 before 27th October, reach out to our support. A dashboard notification will be sent about this deprecation.
  • 13th November: Users are notified via email.
  • 27th November: All Postgres 12 databases are automatically upgraded to Postgres 15.

You will receive three notifications via email before 27th November notifying you about the deprecation of Postgres 12 and deprecation of IPv4 and PGBouncer.


  • The deadline for the migration has been updated to 26th January 2024.
  • You can now purchase a IPv4 address from the add-ons page here if you want to keep using your IPv4 address. More info here.

Moving to IPV6 for Database Connection Strings

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. 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.

Switching to Supavisor

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:

import { drizzle } from 'drizzle-orm/postgres-js'
import postgres from 'postgres'
import { users } from './schema'
// probably an env var
const connectionString = 'postgres://user:[YOUR-PASSWORD]@db.[YOUR-PROJECT-ID]'
const client = postgres(connectionString)
const db = drizzle(client);
const allUsers = await;

you just need to update the connection string to:

import { drizzle } from 'drizzle-orm/postgres-js'
import postgres from 'postgres'
import { users } from './schema'
// probably an env var, get the exact connection string from the database settings page
const connectionString = 'postgres://[db-user]:[db-password]@aws-0-[aws-region][db-name]?options=reference%3D[project-ref]'
const client = postgres(connectionString)
const db = drizzle(client);
const allUsers = await;

PgBouncer and IPv4 deprecation timeline

PgBouncer will be available to use along side Supavisor until January 31st 2024.

The full timeline is:

  • 27 September 2023: Supavisor is available for all new projects.
  • 15 October 2023: Supavisor will be available for all projects, including existing projects. We will notify you via email when it is enabled for your project. PgBouncer is officially deprecated after this date.
  • 15th January 2024 26th January 2024: You will need to start using Supavisor before then.
  • 29th January 2024: Your Supabase database domain ( 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.


Do I need to change anything if I use supabase-js?

For projects which only use the database REST API provided by PostgREST (via supabase-js) there is no action needed.

Will Supabase APIs also be switched to IPv6? will continue to return IPv4 addresses. Only the database domain will return a IPv6 address.

How do I know if my network supports IPv6?

Check if you are able to request your IPv6 address via curl -6

What do I do if I have issues switching?

If you have issues with Supavisor please contact support!

Can I pay for a IPv4 address to directly access the database via IPv4 instead of going through Supavisor?

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.

Can I use PgBouncer and Supavisor at the same time?

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.

supabase --experimental --project-ref <project-ref> postgres-config update --config max_connections=120

How can I tell if I need to make a change?

If the URL you use to connect to your Supabase Database looks like this, you're using the API, and no changes are necessary:


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][db-name]?options=reference%3D[project-ref] or postgres://[db-user].[project-ref]:[db-password]@aws-0-[aws-region][db-name]

If the URL you use to connect looks like this, you are using pgBouncer, and you need to upgrade (notice port 6543):


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:


How will I know if my project has been migrated to IPv6?

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'. CleanShot 2024-01-23@2x

What are the errors that I might see when connecting to the database if my network doesn't support 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 (2001:db8:3333:4444:5555:6666:7777:8888) port 5432 (tcp) failed: Network is unreachable
  • could not translate host name "" to address: nodename nor servname provided, or not known
  • ENETUNREACH 2001:db8:3333:4444:5555:6666:7777:8888
  • Error: P1001: Can't reach database server at
  • (2001:db8:3333:4444:5555:6666:7777:8888), port 5432 failed: could not create socket: Address family not supported by protocol

Note 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.

How will I know if PgBouncer has been removed from my project?

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. CleanShot 2024-01-30

Does Supavisor support prepared statements?

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.

What do I do if I am using Prisma?

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.

How do I update my Vercel Supabase integration?

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.

How do I use direct database connections in my Vercel application instead of using the connection pooler?

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.

Do I need to make any changes if I am using the CLI?

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.

Special Considerations for .NET users using npgSQL

You will need to add Pooling=false to your Supavisor connection string.

Why can't I upgrade my database version anymore?

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.

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:

  • long-requested project transfers between organizations
  • An extra 1GB egress on the Free Tier
  • Consolidated invoices
  • Self-serve Team plan
  • Updates for branching
  • No more “upfront” charges for Database Compute Addons

See all changes in the blog post

Free plan

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 ItemOld plan (per project)New plan (org based)
Egress4GB - (2GB Database + 2GB Storage)5GB across Database + Storage
Database Space500MB500MB
Storage Space1GB1GB
Monthly Active Users50K50K
Edge Function Invocations500K500K
Edge Function Count1010
Realtime Message Count2 million2 million
Realtime Peak Connections200200
2 free projects2 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:

  1. Create a new “Free org”
  2. Transfer one of your free projects into the newly-created org

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

Other changes

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.

Help, my bill increased!

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.

Please keep this discussion on topic

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

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 [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.

select *, 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 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 [email protected].

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 [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.

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 [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.

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.

Error: [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].

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)

This is also available as a blog post.

We're 6 months into building our hosted database platform and we've made some major improvements to our auth system and table view.

Easily create tables

Set up tables and columns directly from the table view.

Create tables from the dashboard

Invite your team

You can now invite team members to your organisation.

Invite team members to Supabase

Auth: Email Confirmations

You can now enable Email Confirmations for new users. This can be toggled on or off and the template for this email can be edited via the dashboard.

Email templates

Typescript support

The biggest communty contribution to date, @thorwebdev added Typescript support to Supabase. He even live streamed the process.

This gif shows how TypeScript makes it even easier to use Supabase, through VSCode's intellisense


We have a number of small improvements:

Alpha July 2020

Aug 5, 2020

Supabase July Alpha Updates

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

After 5 months of building, we're releasing one of our most anticipated features: Supabase Auth.


This month, we're ecstatic to announce a feature we think you'll love: Supabase Auth. It's too big to fit into a monthly update so look out for a full update in the next few days.

We want to make it easy to get started adding Auth to your app, so we've released a simple example and a video tutorial which shows you how to implement a basic auth system using PostgreSQL's Row Level Security.

Table Editor

We've made some massive improvements to our Table Editor that we're excited to share.

Relationship drill down

Last month we made it easy to drill into your table relationships. This month, we make it possible to drill multiple levels deep.

Drill into your releationships

Add, delete, and download rows

We're making it easier to manipulate your data. Next month, you'll be able to add and remove columns directly from the Table view.

Download data as a CSV

New Postgres Extensions

If you launch a new Supabase project, you'll have access to several new Postgres extensions:

  • pgsql-http: HTTP client for PostgreSQL, retrieve a web page from inside the database.
  • pgjwt: PostgreSQL implementation of JSON Web Tokens
  • plpgsql_check: a linter tool for language PL/pgSQL
  • pljava: write Java in your stored procedures, triggers, and functions


We have a number of small improvements:

  • Added Auth documentation to the auto-generated docs in each project
  • Added a new or filter to the client library
  • Table View now remembers which tabs you had open.
  • We have released a lot of new functionality to pg-api, a server for for managing Postgres internals via a REST interface.
  • Performance: the "flash of black" which was appearing on page transition is now gone

Alpha June 2020

Jul 2, 2020

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.



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.


Build in a weekend, scale to millions