Production PostgreSQL is Unhealthy and JobHub cannot load vacancies

[bsanat]

Hello Supabase team,

Our Supabase Production project became unavailable after a restart.

Project:

• Project name: JobHub Production
• Project ref: rpvwnxsyrtoznnmsyyeg
• Region: ap-northeast-1
• Plan: Free Nano

The Supabase dashboard shows:

• Database: Unhealthy
• Auth: Unhealthy
• Storage: Unhealthy
• Realtime: Healthy
• Edge Functions: Healthy
• PostgREST: Disabled

Our JobHub backend cannot connect to PostgreSQL. Vercel logs show:

connect to database: context deadline exceeded
application stopped

Affected requests:

• GET /api/v1/health
• GET /api/v1/jobs
• GET /api/v1/saved-jobs

Supabase logs also showed repeated PostgreSQL recovery events and Supavisor connection timeouts.

We restarted the project once. It became healthy briefly and then returned to Unhealthy. We have not deleted vacancies, run migrations, reset the project, or recreated the database.

Please help us check PostgreSQL, Supavisor, disk I/O, recovery status, and the latest available backup. Please preserve all existing data, vacancies, companies, users, Auth data, and Storage metadata.

We currently use a temporary read-only website fallback because the database is unavailable. We need to restore access to the original Production database.

Thank you.

[supertj]

Sorry you're dealing with this. A crash/recovery loop on Nano is usually a resource problem, and the first priority is getting a copy of your data out.

1. Find out why Postgres keeps restarting

"Repeated recovery events" means Postgres is crashing and replaying WAL on every start. On Nano (0.5 GB RAM, small burst IO) the usual causes are:

• Out of memory: check Logs → Postgres for terminated by signal 9 or server process ... was terminated.
• Disk full: look for No space left on device / could not write. Free projects have 1 GB of disk. The 500 MB database-size quota triggers read-only mode, but WAL and temp files can still fill the disk.
• Disk IO budget exhausted: check Observability → Database Health. Once the daily burst budget is used up, Nano falls back to baseline IO (~250 IOPS). Then health checks and Supavisor connections time out, which matches what you're seeing.

2. Cut the load while it recovers

Your read-only fallback is a good call. Also pause anything that still hits the DB: Vercel crons, background workers, client retries. From Vercel, connect through the Supavisor transaction pooler (port 6543) with a small pool size, not the direct connection. Serverless functions opening new connections on every request can knock a Nano instance over again right after a restart.

3. Take your own backup as soon as it's reachable

Free plan projects don't have downloadable backups, so there may be no "latest backup" you can restore yourself. The next time it's healthy, even briefly, dump everything right away. Use the session pooler string from the Connect dialog (the direct host is IPv6-only):

pg_dump "<session-pooler-connection-string>" -Fc -f jobhub_$(date +%F).dump

This includes the auth and storage schemas (users and Storage metadata). The files inside Storage buckets are not in the dump and need to be downloaded separately.

4. Open a support ticket

GitHub Discussions isn't a support channel. File a ticket at https://supabase.help with your project ref and the log lines above. Only Supabase can inspect the instance, the underlying volume, and any internal snapshots. Until then, don't pause, reset, or restore the project.

If the logs point to OOM or IO, upgrading to Pro with a larger compute size is the most direct fix. It requires a restart, so take the dump first. Pro also gives you daily backups from then on.

---

Longer term, the hardest part of an incident like this is having no backup you control. Keep at least one off-platform copy and actually test restoring it. A nightly pg_dump cron to S3/R2 is enough. Disclosure: I build BackupDrill, which automates this for Supabase with scheduled backups plus restore drills that prove the backups actually work. Happy to help with any of the steps above either way.

[sadaqat120]

Hi @juniorqazaq, sorry you're dealing with this in production. A few things to check: on the free plan, the database can become unhealthy if the disk or memory is full, so look at Reports → Database for disk and memory usage. Also check status.supabase.com for incidents in your region, and open a ticket from the dashboard so support can restart the instance.

If you need hands-on help getting JobHub back and adding backups and monitoring so this doesn't happen again, I'm a full stack developer (Next.js, Supabase, Vercel): https://github.com/sadaqat120

[kannajune]

Hi, hope you've been able to restore the production database. I saw your post about JobHub and the Supabase outage.

Once the database is restored, we may be able to help validate the application's connection handling, recovery behaviour, backups and production reliability.

Is the application back up now, or are you still working through the recovery?