Production DB down 24h+ — disk full, Postgres PANIC crash loop (Free plan, ticket SU-481720)

[brunobiscaino]

Hi everyone! My Supabase project (ref: byaahdtiqrompciqhuqa, Free plan) has been completely unresponsive for 24h+. Support ticket SU-481720 is open, but Free plan has no guaranteed response time, so posting here too in parallel.

What happened: A home-grown daily backup job (pg_cron writing full JSON dumps of every table into a table) filled the disk close to the 500MB soft limit, triggering read-only mode. I tried to clean old rows with an explicit DELETE inside BEGIN/COMMIT (a plain DELETE failed with "cannot execute DELETE in a read-only transaction"). That DELETE's WAL write hit a fully-full disk and crashed Postgres with: PANIC: 53100: could not write to file pg_wal/xlogtemp...: No space left on device. Since then the project has been stuck in a crash loop. Every connection attempt (SQL Editor, Table Editor, REST API, MCP) returns either FATAL: 57P03: the database system is not accepting connections, or ECONNREFUSED / connection timeout.

Question: has anyone hit this exact PANIC-on-full-disk scenario? Is there any self-service way to get the disk bumped (CLI, API, dashboard) without direct staff intervention, or is this strictly a wait-for-support situation? This is a production system for a field-operations team that's been fully down for over a day — any pointers appreciated.

[GaryAustin1]

If restart does not help (unlikely) then your choice is wait for support or upgrade to support (larger disk) and free including micro to pick up a new hardware instance.

[brunobiscaino]

Thanks for the reply! Really appreciate it. Just to confirm: the project has been in this state (FATAL: the database system is not accepting connections / connection timeout) for well over 24h now, so it doesn't look like an automatic restart has happened yet on Supabase's end. Ticket SU-481720 is still open with no response. Is there anything I can do to nudge a restart from the support side, or is this purely a "wait" situation on the Free plan?

[GaryAustin1]

There is no auto restart. You'll have to wait on support or upgrade.

[Mr-Hasan-Hamid]

When Postgres hits a disk-full PANIC on WAL write (could not write to file pg_wal...), it enters an unrecoverable restart loop because the WAL recovery process on container start also needs disk space to replay logs.

To answer your question directly:

• On the Free plan, there is no self-service toggle to expand the volume or run temporary maintenance. Free instances are hard-capped at 500MB, so you normally have to wait for support staff to manually free disk space.
• The immediate self-service bypass: If you cannot wait for the ticket and this is a blocking system, you can upgrade the project to the Pro plan ($25/mo) via the Supabase dashboard (Project Settings > Billing). Upgrading provisions an 8GB+ disk and scales the compute, which instantly gives Postgres the disk headroom it needs to finish WAL recovery and come back online. Once the database is accessible, you can drop or truncate the backup table, run VACUUM FULL, and downgrade back if desired.

[felipe-teo]

The fastest unblock here isn't support — it's the disk. Postgres is in a PANIC/read-only loop because the 500MB free-tier disk is 100% full, and it can't even process your DELETE because the WAL write needs free space too. Upgrading to Pro ($25/mo) bumps you to 8GB+, which breaks the crash loop and lets the DB start; you can trim data and downgrade afterward. That's a self-service path that doesn't wait on SU-481720. Once it's back, if you want, I can help you set up a disk-usage alert and a backup routine that won't fill the disk again — that's usually a one-afternoon fix. Want me to walk you through the upgrade-and-recover steps?