Supabase Free Project Unhealthy — Database Connection Timeout and Disk IO Budget

[dalili1542000-pixel]

Title: Supabase Free Project Unhealthy — Database Connection Timeout and Disk IO Budget

Hello Supabase community,

I need help fixing my Supabase project named starfish.

My project is on the Free plan. The dashboard shows:

• Project status: Unhealthy
• Database: Unhealthy
• PostgREST: Unhealthy
• Auth: Unhealthy
• Storage: Unhealthy
• Disk IO Budget warning
• Table Editor error: “Failed to load schemas — Connection terminated due to connection timeout.”

I restarted the database, but the project still appears unhealthy. My website cannot display stories, and users cannot log in.

I recently migrated story data from Firebase to Supabase. I have not launched my website publicly yet, and I am worried about losing the migrated data.

Could someone please help me understand:

1. Can this problem be fixed on the Free plan, without upgrading?
2. Could the exhausted Disk IO Budget be causing these database connection timeouts?
3. How can I safely restore my database, authentication, and website without deleting my existing data?
4. Should I wait for the Disk IO Budget to replenish, or is there another safe step I should take?

My support ticket ID is SU-500761.

Thank you for your help.

[GaryAustin1]

You need to stop all activity from your app and wait many hours for disk i/o burst to rebuild then try restart again.
Or you need to upgrade to Pro and Micro size which gives you more disk i/o.
Support will likely be days and they may just say you need to upgrade as you have hit the i/o warning.

Only you can decide if this is temporary or not based on your growth rate or what was going on when this happened. The API Gateway logs and charts might be useful for that.

[supertj]

+1 to Gary. Stopping all traffic and letting the IO burst budget refill (or moving to Pro/Micro) is the fix.

On the data-loss worry, a few things that might help:

• An exhausted IO budget or a restart doesn't delete data. The instance is throttled, not wiped. Just avoid reset, pause/restore, or deleting the project while you wait.
• The Firebase migration is the likely trigger. Bulk imports are very IO-heavy and can burn through Nano's daily burst budget quickly. If any import or sync script is still running, stop it first, or the budget won't recover.
• Your source data is still in Firebase, so in the worst case you can re-run the migration. Keep that export until Supabase is stable.
• Back up as soon as it's healthy. Free plan backups can't be downloaded, so once it's back, run pg_dump with the session pooler string from the Connect dialog:
  pg_dump "<session-pooler-url>" -Fc -f starfish.dump
  That covers your tables plus the auth users.

If you re-run the import later, do it in smaller batches spread over time so you stay inside the burst budget.

(Disclosure: I build BackupDrill, which schedules Supabase backups and runs restore tests. A nightly pg_dump cron works too.)