dima/supabase
1
0 Fork 0
mirror of https://github.com/supabase/supabase.git synced 2026-10-05 17:35:10 +03:00
Code Issues Packages Projects Releases Wiki Activity

fix(docs): update upgrading language (#35419)

Browse Source
This commit is contained in:
Inian authored and GitHub committed 2025-05-02 07:33:46 +00:00
1 parent 3aadc009e6
commit c8a5c6736f
1 file changed
+15 -15
Download Patch File Download Diff File Expand all files Collapse all files
apps/docs/content/guides/platform/upgrading.mdx
+15 -15
View File
@@ -4,7 +4,13 @@ title: Upgrading
Supabase ships fast and we endeavor to add all new features to existing projects wherever possible. In some cases, access to new features require upgrading or migrating your Supabase project.
You can upgrade your project using `pg_upgrade` or by pausing and restoring your project.
<Admonition type="tip">
This guide refers to upgrading the Postgres version of your Supabase Project. For scaling your compute size, refer to the [Compute and Disk page](/docs/guides/platform/compute-and-disk).
</Admonition>
You can upgrade your project using in-place upgrades or by pausing and restoring your project.
<ShowUntil date="2024-12-17">
<Admonition type="tip">
@@ -14,33 +20,27 @@ The Migrating and Upgrading guide has been divided into two sections. To migrate
</Admonition>
</ShowUntil>
## `pg_upgrade`
<Admonition type="note">
This upgrade method is currently in Beta.
</Admonition>
## In-place upgrades
<Admonition type="note">
For security purposes, passwords for custom roles are not backed up and, following a restore, they
would need to be reset. See [here](/docs/guides/platform/backups#daily-backups) for more details
</Admonition>
pg_upgrade performs an in-place upgrade on your database. For projects larger than 1GB, pg_upgrade is generally faster than a pause+restore cycle, and the speed advantage grows with the size of the database.
In-place upgrades uses `pg_upgrade`. For projects larger than 1GB, this method is generally faster than a pause and restore cycle, and the speed advantage grows with the size of the database.
1. Plan for an appropriate downtime window, and ensure you have reviewed the [caveats](#caveats) section of this document before executing the upgrade.
1. Use the "Upgrade project" button on the [Infrastructure](https://supabase.com/dashboard/project/_/settings/infrastructure) section of your dashboard.
Additionally, if a pg_upgrade upgrade should fail, your original DB would be brought back up online and be able to service requests.
Additionally, if the upgrade should fail, your original database would be brought back up online and be able to service requests.
As a rough rule of thumb, pg_upgrade operates at ~100MBps (when executing an upgrade on your data). Using the size of your database, you can use this metric to derive an approximate sense of the downtime window necessary for the upgrade. During this window, you should plan for your DB and associated services to be unavailable.
As a rough rule of thumb, pg_upgrade operates at ~100MBps (when executing an upgrade on your data). Using the size of your database, you can use this metric to derive an approximate sense of the downtime window necessary for the upgrade. During this window, you should plan for your database and associated services to be unavailable.
## Pause and restore
<Admonition type="note">
We recommend using the pg_upgrade method, as it is faster, and more reliable. Additionally, only Free-tier projects are eligible to use the Pause + Restore method.
We recommend using the In-place upgrade method, as it is faster, and more reliable. Additionally, only Free-tier projects are eligible to use the Pause and Restore method.
</Admonition>
@@ -106,18 +106,18 @@ When upgrading, the Supabase platform will "right-size" your disk based on the c
#### Objects dependent on Postgres extensions
pg_upgrade does not support upgrading of databases containing reg\* data types referencing system OIDs.
In-place upgrades do not support upgrading of databases containing reg\* data types referencing system OIDs.
If you have created any objects that depend on the following extensions, you will need to recreate them after the upgrade.
#### `pg_cron` records
[pg_cron](https://github.com/citusdata/pg_cron#viewing-job-run-details) does not automatically clean up historical records. This can lead to extremely large `cron.job_run_details` tables if the records are not regularly pruned; you should clean unnecessary records from this table prior to an upgrade.
During the `pg_upgrade` process, the `pg_cron` extension gets dropped and recreated. Prior to this process, the `cron.job_run_details` table is duplicated to avoid losing historical logs. The instantaneous disk pressure created by duplicating an extremely large details table can cause at best unnecessary performance degradation, or at worst, upgrade process failures.
During an in-place upgrade, the `pg_cron` extension gets dropped and recreated. Prior to this process, the `cron.job_run_details` table is duplicated to avoid losing historical logs. The instantaneous disk pressure created by duplicating an extremely large details table can cause at best unnecessary performance degradation, or at worst, upgrade process failures.
#### Extensions
pg_upgrade does not currently support upgrading of databases using extensions older than the following versions:
In-place upgrades do not currently support upgrading of databases using extensions older than the following versions:
- TimescaleDB 2.16.1
- plv8 3.1.10