Urgent Supabase/Postgres Developer Needed to Debug Stuck Background Jobs

We need an experienced Supabase/Postgres developer to help us urgently debug and stabilize a production workflow. We have a front-facing app/project that relies on Supabase, Postgres, PostgREST, and background job processing. Recently, several jobs became stuck after our Supabase project exceeded usage limits and later started hitting Disk I/O budget warnings. We temporarily removed the spend cap and upgraded compute/Disk I/O, but we still need a developer to properly diagnose and fix the underlying issue. The main issue is with background jobs related to prospecting and categorization. Some jobs are stuck, partially processed, or not being picked up consistently by the worker/queue. We need someone who can inspect the database structure, understand the queue logic, check logs, identify bottlenecks, and implement a reliable fix. This is not a basic front-end task. We need someone who is strong with Supabase, Postgres, SQL, queues/background workers, and production debugging. We are seeing issues like: Jobs stuck in partial progress states. Prospecting jobs stuck with completed = NULL and partial domains_completed. Queue rows partially processed in prospecting_queue. Supabase PostgREST errors such as 520 / 524. Front-facing project slowing down to 30–60 second load times. Supabase warning: project close to depleting Disk I/O Budget. Some jobs only move after manual SQL intervention, then stall again. Storage was over quota, but current issue appears related to database/API/worker performance too. What We Need You To Do Your job will be to: Review the Supabase database schema and queue/job tables. Identify why specific jobs are getting stuck or not restarting properly. Check PostgREST / database logs for timeouts, 520/524 errors, long-running queries, and disk I/O bottlenecks. Determine whether the issue is: database performance, a broken queue condition, a stuck worker, missing indexes, oversized inserts, bad retry logic, provider/API rate limits, or something else. Safely restart/reprocess the stuck jobs without corrupting data. Recommend and/or implement a more reliable job retry/recovery system. Help us prevent this from happening again. Ideal Candidate You should have real experience with: Supabase PostgreSQL PostgREST SQL debugging Background jobs / queue systems Database performance optimization Long-running query analysis Indexing and query tuning Production incident debugging JavaScript/TypeScript backends, Edge Functions, or similar worker systems Bonus if you have experience with: Supabase Edge Functions Vercel / Render / Railway / serverless workers Queue retry logic API integrations like Hunter, Snov.io, Clearbit, RocketReach, Apify, etc. Data pipelines that process spreadsheet rows/domains What Success Looks Like We want to end this engagement with: The stuck jobs restarted or safely resolved. The front-facing project loading normally again. Clear explanation of what caused the issue. Clear recommendation for whether we need additional Supabase compute, better indexing, different queue design, or worker changes. Better protection against jobs getting permanently stuck in the future. A simple operating procedure for safely retrying failed jobs. Immediate Priority This is urgent. We would like someone available today or within the next 24 hours. We can start with a short paid diagnostic session where you screen share with us, inspect Supabase, review logs, and identify the likely fix. Please Include In Your Proposal Please answer these: Have you debugged Supabase/Postgres production performance issues before? Have you worked with background job queues or worker processes? How would you approach diagnosing stuck jobs in Supabase? Are you comfortable reviewing SQL tables, views, logs, and long-running queries? Are you available for a same-day or next-day debugging session? Please do not apply if your experience is mainly front-end only. We need someone comfortable debugging the database/backend side of a production system.