Skip to content

How to bypass cooldown period

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.

See the AWS docs for more on how Amazon EBS itself throttles volume modifications.

There are a few options to work around the cooldown, depending on the state of your database:

  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.
  2. pg_upgrade: Our pg_upgrade 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 first.

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.