How to bypass modification limits

这个限制不是 Supabase 的限制。这是因为 Amazon EBS（我们数据库底层的存储）在管理卷修改时的方式造成的。AWS 允许每个卷在滚动的 24 小时内最多进行四次修改。虽然你可以在上一次修改完成后立即开始新的修改，但 AWS 会执行一个配额，防止在这 24 小时内进行第五次修改，以确保数据的完整性和卷的稳定性。

🌐 This limit is not a Supabase limitation. It is rooted in how Amazon EBS (the underlying storage for our databases) manages volume modifications. AWS allows up to four modifications per volume within a rolling 24-hour window. While you can start a new modification immediately after a previous one completes, AWS enforces a quota that prevents a fifth modification within that 24-hour period to ensure data integrity and volume stability.

来自AWS 文档：

🌐 From the AWS docs:

在你发起卷修改之后，你必须等这个修改完成后才能对同一个大括号起另一次修改。只要卷处于使用中或可用状态，并且该卷之前的所有修改都已完成，你可以在滚动的 24 小时内修改卷最多四次。如果超过这个限制，你会收到一个错误信息，告诉你下一次可以执行修改的时间。

如果你已经用了四次修改，但还需要做进一步调整，有几种方法可以绕过这个限制：

🌐 There are a few options to work around this limit if you have already used your four modifications and need to make further adjustments:

1. 恢复到新项目：这会启动一个带有新磁盘的新实例，完全绕过 24 小时配额。如果你可以接受创建新项目和重构项目，这是一个不错的选择。文档：恢复到新项目。
2. pg_upgrade：我们的pg_upgrade 实现会将你的数据迁移到一个新的磁盘，这会重置修改计数。这里的主要要求是数据库必须处于可运行状态——如果你的数据库处于降级或无法访问的状态，pg_upgrade 是无法运行的。
3. 暂停并恢复：这也会迁移到新磁盘，但仅适用于免费计划的项目。如果你不在免费计划上，你需要先将你的项目转移到免费计划的组织。

如果数据库宕机或处于异常状态（例如，损坏或在调整大小时卡住），而你又达到了修改次数的限制，那么唯一的办法就是等到滚动的 24 小时窗口允许进行下一次修改。

🌐 If the database is down or locked in a bad state (e.g., corrupted or stuck during resize), and you have hit the modification limit, the only path forward is to wait until the rolling 24-hour window allows for another modification.

更多相关信息请参见我们的文档：https://supabase.com/docs/guides/platform/database-size#disk-size。

🌐 More on this in our doc here: https://supabase.com/docs/guides/platform/database-size#disk-size.