Project unhealthy, disk full, FATAL 57P03 "not accepting connections" (Free plan, eu-west-3)

[nijatahmadzada]

Project ref: kphknfkbeajxgitnaclj (eu-west-3, Free plan, Nano)

The project went into read-only mode a few days ago. The database is 1.5 GB and
almost all of it is auth bookkeeping: a crawler that renders JavaScript kept
triggering anonymous sign-ins, which left 1.1M rows in auth.users, auth.sessions,
auth.refresh_tokens and auth.mfa_amr_claims. Only 23 accounts are real.

I disabled read-only mode from the dashboard and started deleting the empty
anonymous users in batches of 5,000 so the database would get back under the
limit. After about 15,000 rows the disk went from 95% to 100% and the database
stopped accepting connections:

FATAL: 57P03 the database system is not accepting connections
Hot standby mode is disabled.

The project now shows Status: Unhealthy, Disk 97%, "Conns Unavailable". I have
not paused or restarted it, and I am not connecting to it any more.

Could you help bring the instance back up? Once it accepts connections I only
need one statement, which frees about 1 GB instantly with almost no WAL:

truncate table auth.refresh_tokens, auth.sessions, auth.mfa_amr_claims;

After that the database drops well under the Free plan limit and stays there —
the application no longer creates an anonymous user on page load, and the
crawler is blocked in robots.txt.

[BryceEWatson]

Your plan looks right to me, and it explains why the batched deletes backfired: every delete is written to the WAL first, and the space isn't given back until a vacuum, so deleting on a nearly full disk uses more disk before it frees any. TRUNCATE drops the files outright, so it's the better move. Since the instance won't accept connections, bringing it back is on Supabase's side, so I'd also open a ticket from the dashboard's Support page with the project ref and the 57P03 error if you haven't already. A few things for after it's back:

1. Truncating auth.sessions and auth.refresh_tokens signs everyone out, including your 23 real users, so they'll need to log in again. Worth a heads-up if any of them are active. If the SQL editor won't let you truncate the auth tables, ask support to run that statement while they have the instance up.
2. The 1.1M rows in auth.users will still be there. Once you've got headroom, delete them in batches with a vacuum in between, using the is_anonymous column so you don't touch real accounts. Supabase's docs have a cleanup query you can schedule with pg_cron: delete from auth.users where is_anonymous is true and created_at < now() - interval '30 days';
3. Removing the sign-in on page load stops this crawler, but if anonymous sign-ins are still switched on in your Auth settings, anyone with your public anon key can call that endpoint directly, and robots.txt only stops crawlers that choose to obey it. If you don't need anonymous users any more, I'd switch them off. If you do, Supabase recommends invisible CAPTCHA or Cloudflare Turnstile for them, and you can lower the per-IP limit (30 an hour by default) in the dashboard's Auth rate limits.

Docs: https://supabase.com/docs/guides/auth/auth-anonymous and https://supabase.com/docs/guides/platform/database-size