diff --git a/apps/docs/content/guides/platform/compute-and-disk.mdx b/apps/docs/content/guides/platform/compute-and-disk.mdx
index d425676ec42..66c8694561a 100644
--- a/apps/docs/content/guides/platform/compute-and-disk.mdx
+++ b/apps/docs/content/guides/platform/compute-and-disk.mdx
@@ -166,5 +166,5 @@ As mentioned in the Postgres [documentation](https://postgresqlco.nf/doc/en/para
### Constraints
-- You can modify disk attributes up to **four times** within a rolling 24-hour window. A new modification can be initiated as soon as the previous one completes. If you reach this limit, you will encounter throttling and must wait for the rolling 24-hour window to permit further adjustments.
+- After **any** disk attribute change, there is a cooldown period of approximately four hours before you can make further adjustments. During this time, no changes are allowed. If you encounter throttling, you’ll need to wait until the cooldown period concludes before making additional modifications.
- You can increase disk size but cannot decrease it.
diff --git a/apps/docs/content/guides/platform/database-size.mdx b/apps/docs/content/guides/platform/database-size.mdx
index 0e1f1b0dab5..bf8532ebd3d 100644
--- a/apps/docs/content/guides/platform/database-size.mdx
+++ b/apps/docs/content/guides/platform/database-size.mdx
@@ -87,9 +87,7 @@ Supabase uses network-attached storage to balance performance with scalability.
Projects on the Pro Plan and higher have auto-scaling disks.
-Disk size expands automatically when the database reaches 90% of the allocated disk size. The disk is expanded to be 50% larger (for example, 8 GB -> 12 GB).
-
-Auto-scaling is limited to four modifications within a rolling 24-hour window. While a new modification can be initiated immediately after the previous one completes, reaching the quota of four resizes within the current rolling 24-hour window will prevent further scaling until the window allows it. If you reach 95% disk utilization and have exhausted your modification quota, your project will enter read-only mode.
+Disk size expands automatically when the database reaches 90% of the allocated disk size. The disk is expanded to be 50% larger (for example, 8 GB -> 12 GB). Auto-scaling is limited to four modifications within a rolling 24-hour window. If you reach 95% disk utilization and have exhausted your modification quota, your project will enter read-only mode.
@@ -103,7 +101,7 @@ Disk size can also be manually expanded on the [Database Settings page](/dashboa
You may want to import a lot of data into your database which requires multiple disk expansions. for example, uploading more than 1.5x the current size of your database storage will put your database into [read-only mode](#read-only-mode). If so, it is highly recommended you increase the disk size manually on the [Database Settings page](/dashboard/project/_/database/settings).
-Due to restrictions on the underlying cloud provider, disk modifications are limited to four operations within a rolling 24-hour window. While a new modification can be initiated as soon as the previous one completes, you will be unable to make further adjustments if you reach this rolling 24-hour limit until the rolling 24-hour window permits it.
+Due to restrictions on the underlying cloud provider, disk expansions can occur only once every four hours. During the four hour cool down window, the disk cannot be resized again.
diff --git a/apps/docs/content/troubleshooting/high-cpu-and-slow-queries-with-error-must-be-a-superuser-to-terminate-superuser-process.mdx b/apps/docs/content/troubleshooting/high-cpu-and-slow-queries-with-error-must-be-a-superuser-to-terminate-superuser-process.mdx
index 95a5ec2db0b..d417d49d841 100644
--- a/apps/docs/content/troubleshooting/high-cpu-and-slow-queries-with-error-must-be-a-superuser-to-terminate-superuser-process.mdx
+++ b/apps/docs/content/troubleshooting/high-cpu-and-slow-queries-with-error-must-be-a-superuser-to-terminate-superuser-process.mdx
@@ -50,7 +50,7 @@ Since the wraparound prevention autovacuum cannot be stopped, the best approach
2. **Increase Disk Throughput/IOPS:**
- **Action:** If disk I/O utilization is also consistently high (e.g., near 100%), consider temporarily increasing your disk's provisioned IOPS and throughput.
- **Why it helps:** Autovacuum is an I/O-intensive operation, involving a lot of reading and writing. Higher disk performance can significantly speed up the process.
- - **Considerations:** Cloud providers may limit the number of disk modifications (e.g., up to four in a rolling 24-hour window). You can start a new modification immediately after the previous one finishes, provided you have not exceeded this rolling 24-hour quota.
+ - **Considerations:** Cloud providers often have limitations, such as a cooldown period (e.g., 4 hours) between disk modification operations.
## Monitoring progress and future prevention
diff --git a/apps/docs/content/troubleshooting/how-to-bypass-cooldown-period.mdx b/apps/docs/content/troubleshooting/how-to-bypass-cooldown-period.mdx
index 324673eaf78..53d114e7db5 100644
--- a/apps/docs/content/troubleshooting/how-to-bypass-cooldown-period.mdx
+++ b/apps/docs/content/troubleshooting/how-to-bypass-cooldown-period.mdx
@@ -1,22 +1,20 @@
---
-title = "How to bypass modification limits"
+title = "How to bypass cooldown period"
topics = [ "platform" ]
-keywords = [ "modification limits", "disk resize" ]
+keywords = [ "cooldown", "disk resize" ]
database_id = "6f6a34a6-ac3f-4fba-9c70-4f4b8c7aeda7"
---
-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.
+This cooldown isn't an arbitrary Supabase restriction — it's rooted in how Amazon EBS (the underlying storage for our databases) limits volume modifications to up to four times within a rolling 24-hour window. To keep this predictable, Supabase enforces a 4-hour cooldown after each manual disk modification (e.g. increasing size, changing type, or IOPS) before allowing another one on the same volume. This helps ensure data integrity and stability of the volume under load.
-From the [**AWS docs**](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyVolume.html):
+See the [**AWS docs**](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyVolume.html) for more on how Amazon EBS itself throttles volume modifications.
-> After you initiate a volume modification, you must wait for that modification to reach the completed state before you can initiate another modification for the same volume. You can modify a volume up to four times within a rolling 24-hour period, as long as the volume is in the in-use or available state, and all previous modifications for that volume are completed. If you exceed this limit, you get an error message that indicates when you can perform your next modification.
+There are a few options to work around the cooldown, depending on the state of your database:
-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. **Restore to a new project**: This spins up a new instance with a new disk, bypassing the 24-hour quota entirely. It’s a great option if you're okay with a new project and project refactoring. [**Docs: restoring to a new project**](/docs/guides/platform/backups#restore-to-a-new-project).
-2. **pg_upgrade**: Our [**pg_upgrade**](/docs/guides/platform/upgrading) implementation migrates your data to a new disk, which resets the modification count. The main requirement here is that the database must be operational - pg_upgrade can't run if your database is in a degraded or inaccessible state.
+1. **Restore to a new project**: This spins up a new instance with a new disk, bypassing the cooldown entirely. It’s a great option if you're okay with a new project and project refactoring. [**Docs: restoring to a new project**](/docs/guides/platform/backups#restore-to-a-new-project).
+2. **pg_upgrade**: Our [**pg_upgrade**](/docs/guides/platform/upgrading) implementation migrates your data to a new disk, which skips the cooldown. The main requirement here is that the database must be operational - pg_upgrade can't run if your database is in a degraded or inaccessible state.
3. **Pause and Restore**: This also migrates to a new disk but is only available for projects on the Free plan. If you're not on the Free plan, you'd need to [**transfer your project to an organization on the Free plan**](/docs/guides/platform/project-transfer) first.
-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.
+If the database is down or locked in a bad state (e.g., corrupted or stuck during resize), the only path forward is to wait until the cooldown expires and the disk resize job completes in the queue.
More on this in our doc here: [**https://supabase.com/docs/guides/platform/database-size#disk-size**](/docs/guides/platform/database-size#disk-size).
diff --git a/apps/studio/components/interfaces/DiskManagement/DiskManagementForm.sections.tsx b/apps/studio/components/interfaces/DiskManagement/DiskManagementForm.sections.tsx
index 1dcdceda2f1..35e020757b1 100644
--- a/apps/studio/components/interfaces/DiskManagement/DiskManagementForm.sections.tsx
+++ b/apps/studio/components/interfaces/DiskManagement/DiskManagementForm.sections.tsx
@@ -297,7 +297,7 @@ export function AdvancedSection({
isDiskTooSmallForCustomIops && !disableIopsThroughputConfig && !disableDiskInputs
}
title="Increase disk size to adjust IOPS or throughput"
- description={`This disk is too small to update IOPS or throughput, since gp3 volumes are capped at 500 IOPS per GB with a 3,000 IOPS minimum. Resizing to ${suggestedDiskSizeForCustomIops} GB unlocks custom IOPS and throughput, and leaves headroom for further adjustments (disk config changes are limited to 4 within a rolling 24-hour window).`}
+ description={`This disk is too small to update IOPS or throughput, since gp3 volumes are capped at 500 IOPS per GB with a 3,000 IOPS minimum. Resizing to ${suggestedDiskSizeForCustomIops} GB unlocks custom IOPS and throughput, and leaves headroom for further adjustments (disk config changes are locked for 4 hours after each resize).`}
actions={
!disableDiskSizeInput ? (