升级

Supabase 快速迭代，我们努力将所有新功能添加到现有项目中。在某些情况下，访问新功能需要升级或迁移您的 Supabase 项目。

您可以使用就地升级或暂停并恢复项目来升级项目。

就地升级#

就地升级使用 pg_upgrade。对于大于 1GB 的项目，此方法通常比暂停和恢复周期更快，并且速度优势随着数据库大小的增加而增加。

1. 规划适当的停机窗口，并在执行升级之前查看本文档的 注意事项 部分。
2. 使用仪表板的 基础设施 部分中的“升级项目”按钮。

此外，如果升级失败，您的原始数据库将被重新上线并能够处理请求。

作为粗略的经验法则，pg_upgrade 以约 100MBps 的速度运行（在对您的数据执行升级时）。使用数据库的大小，您可以使用此指标来大致了解升级所需的停机窗口。在此窗口期间，您应该计划您的数据库和相关服务不可用。

暂停和恢复#

当您暂停并恢复项目时，恢复的数据库包含最新的功能。此方法确实包含停机时间，因此请注意您的项目在此期间将无法访问。

1. 在仪表板的 常规设置 页面上，单击 暂停项目。您的项目正在暂停时，您将被重定向到主屏幕。此过程可能需要几分钟。
2. 项目暂停后，单击 恢复项目。恢复时间取决于数据库的数据量，可能需要几分钟。恢复完成后您将收到电子邮件。

请注意，暂停 + 恢复升级涉及在重新启动项目资源之前将其拆除。如果恢复过程失败，需要 Supabase 支持人员手动干预才能使您的项目重新上线。

注意事项#

无论升级方法如何，都适用一些注意事项

逻辑复制#

如果您正在使用逻辑复制，则升级过程不会保留复制槽。您需要在升级后使用 pg_create_logical_replication_slot 方法手动重新创建它们。有关该方法的更多详细信息，请参阅 Postgres 文档中的 复制管理函数。

破坏性变更#

新版本的服务可能会破坏您依赖的功能或更改性能特征。如果您的项目有资格升级，您可以在 Supabase 仪表板 中找到您当前的服务版本。

破坏性变更通常只存在于 Postgres 和 PostgREST 的主要版本升级中。您可以在以下位置找到它们各自的发行说明：

• Postgres
• PostgREST

如果您是从一个较旧的版本升级，您还需要考虑任何中间版本的发行说明。

时间限制#

从 2024-06-24 开始，当项目暂停时，用户在 Supabase Studio 平台内恢复项目有 90 天的时间窗口。

90 天的窗口允许 Supabase 引入可能与旧备份不兼容的平台更改。与活动项目不同，静态备份无法更新以适应这些更改。

在 90 天的恢复窗口期间，可以从 Studio 的仪表板页面 单击一个按钮将暂停的项目恢复到平台。

90 天的恢复窗口过后，您可以从项目仪表板下载项目的备份文件和存储对象。您可以通过以下方式恢复数据：

• 将备份恢复到新的 Supabase 项目
• 在本地恢复备份

如果您在 90 天的恢复窗口内升级到付费计划，任何过期的单击恢复选项将被重新启用。由于备份是在向后兼容性窗口之外拍摄的，因此可能无法恢复。如果您在升级后恢复备份时遇到问题，请联系 支持。

磁盘大小调整#

在升级时，Supabase 平台将根据当前数据库大小“调整”您的磁盘大小。例如，如果您的数据库大小为 100GB，而您拥有 200GB 的磁盘，则升级会将磁盘大小减少到 120GB（数据库大小的 1.2 倍）。

依赖 Postgres 扩展的对象#

就地升级不支持升级包含引用系统 OID 的 reg* 数据类型的数据库。如果您创建了任何依赖以下扩展的对象，则需要在升级后重新创建它们。

pg_cron 记录#

pg_cron 不会自动清理历史记录。如果未定期修剪记录，这可能导致 cron.job_run_details 表变得非常大；您应该在升级之前清理此表中的不必要记录。

在就地升级期间，pg_cron 扩展将被删除并重新创建。在此过程之前，cron.job_run_details 表将被复制以避免丢失历史记录。复制一个非常大的详细表产生的瞬时磁盘压力，最多会导致不必要的性能下降，最坏的情况是导致升级过程失败。

扩展#

就地升级目前不支持使用以下版本以下的扩展的数据库：

• TimescaleDB 2.16.1
• plv8 3.1.10

要升级到较新版本的 Postgres，您需要在升级之前删除扩展，并在升级后重新创建它们。

身份验证方法更改 - 弃用 md5 以支持 scram-sha-256#

md5 散列方法存在 已知漏洞，使其不适合用于密码学。因此，我们正在弃用 md5，以支持 scram-sha-256，这是最新 Postgres 版本中默认且最安全的身份验证方法。

我们在升级过程中自动将 Supabase 管理的角色的密码迁移到 scram-sha-256，但您需要手动迁移您创建的任何自定义角色的密码，否则在升级后将无法使用它们进行连接。

要识别使用 md5 散列方法的角色并迁移其密码，您可以在升级后使用以下 SQL 语句：

1
-- List roles using md5 hashing method
2
SELECT
3
  rolname
4
FROM pg_authid
5
WHERE rolcanlogin = true
6
  AND rolpassword LIKE 'md5%';
7
8
-- Migrate a role's password to scram-sha-256
9
ALTER ROLE <role_name> WITH PASSWORD '<password>';

数据库大小缩减#

作为升级过程的一部分，还会执行维护操作，例如 vacuuming。这可能会导致报告的数据库大小减少。

升级后验证#

Supabase 执行广泛的升级前和升级后验证，以确保数据库已正确升级。但是，您应该计划进行自己的应用程序级别验证，因为您可能没有预料到的更改，并且在规划停机窗口时应将其考虑在内。

特定升级说明#

升级到 Postgres 17#

在 Postgres 17 中使用的项目中，以下扩展已被弃用：

• plcoffee
• plls
• plv8
• timescaledb
• pgjwt

计划从 Postgres 15 升级到 Postgres 17 的项目需要在 Supabase 仪表板 中首先禁用这些扩展。

pgjwt 在 Postgres 17 之前在每个 Supabase 项目中默认启用。如果您没有在项目中显式使用 pgjwt，则很可能可以安全地禁用它。

较低版本的 Postgres 上的现有项目不受影响，并且这些扩展将继续在 Postgres 15 项目上受支持，直到 Supabase 平台上的 Postgres 15 生命周期结束。