Changelog

We've improved insights into usage, billing and costs.

Vastly improved usage summary#

We previously had a slightly hidden usage summary in the "Upcoming Invoice" section. This section has been revamped and moved to the organization's usage page.

The improved usage summary features:

• Per-project breakdown for usage
• Displays costs for over-usage on usage-based plans (pro with spend cap off, team, enterprise)
• Displays usage in percent for usage-capped plans (free/pro with spend cap on)
• Metrics with higher usage/costs will be sorted to the top
• Insights into compute usage in summary
• Usage can now be retrieved for a custom period and not just the current billing cycle
• Usage summary can be filtered by project
• Indicators if you're exceeding/approaching limits which could lead to restrictions

The new usage summary section (usage-capped plan):

New usage summary with a usage-based plan (Pro with spend cap off, Team, Enterprise):

When hovering over the circular progress bars, you get per-project breakdowns of usage and some further information:

We now also allow you to filter the total usage by a single project or a different period than the current billing cycle. Simply change the timeframe at the top of the usage page.

Usage filtered with a custom timeframe (not relative to billing cycle):

Daily Stats for Compute Usage#

The organization's usage page shows daily stats for all sorts of usage-based metrics and was still missing insights for compute hours. Compute Usage insights have been added to the usage page.

New section on the usage page:

Sample usage with a single project:

When running multiple projects or projects on different compute sizes:

Better insights for upcoming invoice#

The "Upcoming invoice" section on the organization billing page has been vastly improved and now offers per-project breakdown of metrics and project add-ons. Additionally, there is a simple projection of your cost at the end of the month.

Here's an overview of the new section with all project breakdowns collapsed:

You can expand any usage-based item or project add-on to get a per-project breakdown:

The line items have also been improved to show included quotas and costs for over-usage:

Quickly see if you're exceeding your plans limit#

On usage-capped plans (Free Plan or Pro Plan with Spend Cap toggled on), you will now also see a warning on the top of the subscription page, in case you're exceeding your plan's limits. A more detailed breakdown is available on the organization's usage page.

Project breakdown for subscription preview#

When you are about to upgrade your organization's subscription plan from free to paid or between paid plans, we show you a confirmation screen. That confirmation screen has been improved to show a per-project breakdown for compute costs. Additionally, some useful information about usage-billing for compute and links to related docs have been added.

New confirmation modal:

Break down add-ons on a per-project basis:

Education about usage-billing for compute, mixing paid/non-paid plans and links to related docs:

Table Editor row edit side panel fix boolean fields rendering stale value#

There was issue in the Table Editor when you're editing rows in the side panel, specifically for column types that are rendering the Listbox component, whereby the data rendered in that input field is stale (from the previous row that you opened). This was caused by the Listbox component not re-rendering correctly when the value passed to it has changed and is now fixed.

PR: https://github.com/supabase/supabase/pull/19264 Link: https://supabase.com/dashboard/project/_/editor

Added recommendation to enable PITR when enabling branching#

We strongly recommend enabling point in time recovery for your project if you're planning to enable branching. This is to ensure that you can always recover data if you make a "bad migration". For example, if you accidentally delete a column or some of your production data.

PR: https://github.com/supabase/supabase/pull/19324 Link: https://supabase.com/dashboard/project/_/

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.

Allow access to backups page while project is restoring to download scheduled backups#

PR: https://github.com/supabase/supabase/pull/19126 Link: https://supabase.com/dashboard/project/_/database/backups/scheduled

Show if a member has MFA enabled or not in organization settings page#

PR: https://github.com/supabase/supabase/pull/19012 Link: https://supabase.com/dashboard/org/_/team

Show which email support will reach out to after submitting a ticket#

PR: https://github.com/supabase/supabase/pull/19095 Link: https://supabase.com/dashboard/support/new

Added wildcard hints for bucket allowed MIME types in create/edit modal#

PR: https://github.com/supabase/supabase/pull/19062 Link: https://supabase.com/dashboard/project/_/storage/buckets

SQL Editor support downloading snippet as a migration, a seed file or a SQL file#

PR: https://github.com/supabase/supabase/pull/17341 Link: https://supabase.com/dashboard/project/_/sql/new

Table Editor fix freezing a column causes UI to crash#

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

tldr:#

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.

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

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.