Database Infrastructure Issue - Basic Queries Timing Out

[ProMicke]

My database has become completely unresponsive as of today. Even basic operations are failing:

• SELECT COUNT(*) FROM job_openings - TIMEOUT
• ANALYZE job_openings - TIMEOUT (initially, succeeded after retry)
• All RPC functions - TIMEOUT with error code 57014

TIMELINE:

• Application worked perfectly for 4 months
• Yesterday: 450k records, fast performance
• Today: 500k records, everything times out
• Current: Reduced to 400k records, still timing out

This appears to be a critical infrastructure issue.

Anyone else that has this issue the past days?

[guomengtao]

Hi ProMicke,
I’m sorry to hear your database is completely unresponsive—this must be really disruptive to your workflow, especially since it was working perfectly just yesterday. Let’s break down how to troubleshoot this and get clarity on whether it’s an isolated issue or platform-wide:

1. First: Check if it’s a Supabase platform-wide infrastructure issue (fastest way to rule out big problems)
   Before diving into your database config, let’s confirm if this is related to Supabase’s own infrastructure (since you mentioned it feels like an "infrastructure issue"):
   Go to the Supabase Status Page (https://status.supabase.com/)—look for any ongoing incidents under "Database" or your specific region (e.g., "US East 1"). If there’s a known outage or degradation, Supabase will list it here (and update when it’s fixed).
   Check the Supabase Community Forum (https://github.com/supabase/supabase/discussions) or Discord (https://discord.com/invite/supabase)—search for keywords like "query timeout" or your region + "unresponsive" to see if other users reported similar issues in the last 24 hours.
   If others are facing this, it’s likely a platform issue, and Supabase’s team will be addressing it. If not, we can focus on your database’s specific setup.
2. If it’s isolated to your database: Troubleshoot common "sudden timeout" causes (even with small data growth)
   A 50k record increase (450k→500k) shouldn’t cause timeouts on basic queries—here are the most likely culprits to check right now (all accessible via your Supabase Dashboard):
   A. Check for long-running "blocking queries" (the Add Realtime, allowing realtime-js to initialise sockets from inside #1 cause of sudden timeouts)
   Even a single stuck query can lock tables and block all other operations (e.g., a forgotten UPDATE without a WHERE clause, or a complex join that’s been running for hours).
   Go to your Supabase Dashboard → Database → Query Editor → Active Queries (or "Running Queries"—location varies by region).
   Look for queries that have been running for >5 minutes (or longer than usual). If you find any, terminate them (there’s a "Kill Query" button) and test your SELECT COUNT() again.
   B. Verify your database’s resource limits (did you hit CPU/memory constraints?)
   Supabase’s free/Pro tiers have resource limits (e.g., CPU usage, connection count). Even small traffic spikes can push you over limits, causing timeouts:
   Go to Supabase Dashboard → Settings → Billing & Usage → Usage—check if you’ve hit 100% CPU, memory, or "Database Connections" in the last 24 hours.
   If you’re on the Free tier: Note that it has strict CPU limits (for burst usage). If you saw a small traffic jump yesterday, it might have exhausted resources (even if data size is small). Upgrading to Pro (temporarily, for testing) can confirm if this is the issue.
   C. Check table indexes (did a missing/index issue break after data growth?)
   While you mentioned ANALYZE eventually succeeded, a missing or outdated index can make even COUNT() slow on 500k records (though timeout is extreme—this is more of a "double-check" step):
   For the job_openings table: Run \d job_openings in the Query Editor to list indexes. If you frequently query/filter by columns (e.g., status, location), ensure there’s an index on those columns.
   If indexes exist: Run REINDEX TABLE job_openings; (this may take time, but it fixes corrupted indexes that can cause unexpected slowdowns).
3. If none of the above works: Escalate to Supabase Support immediately
   Since this is a critical outage, don’t wait—Supabase’s support team can access infrastructure-level logs you can’t:
   Go to Supabase Dashboard → Support → Open a Ticket (or use the "Help" button in the bottom-right).
   Include these details to speed up resolution:
   Your Supabase project ID (found in Settings → General).
   The exact region of your database (e.g., "eu-west-1").
   Screenshots of timeouts (e.g., the SELECT COUNT(*) error message) and resource usage (CPU/memory from Billing & Usage).
   Timeline recap (4 months stable → yesterday 450k → today 500k timeout → reduced to 400k still broken).
   Supabase’s team prioritizes critical database outages, so this will get you faster help than waiting for forum replies.
   I’ll keep an eye on this thread—if you find out it’s a platform issue (or fix it with one of the steps above), feel free to update here to help other users! Hope you get this resolved soon.

[ProMicke]

Hi Tom, Thanks for the quick answer! I've tried the steps below with no success. FYI, I've got pro-tier already (with SMALL tier for compute). Strangely, itstarted working good out of nowhere (some hours after deleting around 100k records). Then I filled it again with 100k records, and now it dosen't work anymore once again. I've done some research, and the thing is that the most important thing that needs to work for my application is the IVFFlat indexes (for my AI semantic search). According to some research, it seems like I should use HNSW index instead, which can handle a lot more records. I tried to replace IVFFLAT with HNSW (for semantic search) in this job_openings table, but I keep getting timeouts. How can we solve this? Should I proceed to Best regards, Michael

…

________________________________ Från: Tom Jones ***@***.***> Skickat: den 25 augusti 2025 12:24 Till: supabase/supabase ***@***.***> Kopia: ProMicke ***@***.***>; Author ***@***.***> Ämne: Re: [supabase/supabase] Database Infrastructure Issue - Basic Queries Timing Out (Discussion #38172) Hi ProMicke, I’m sorry to hear your database is completely unresponsive—this must be really disruptive to your workflow, especially since it was working perfectly just yesterday. Let’s break down how to troubleshoot this and get clarity on whether it’s an isolated issue or platform-wide: 1. First: Check if it’s a Supabase platform-wide infrastructure issue (fastest way to rule out big problems) Before diving into your database config, let’s confirm if this is related to Supabase’s own infrastructure (since you mentioned it feels like an "infrastructure issue"): Go to the Supabase Status Page (https://status.supabase.com/)—look<https://status.supabase.com/)%E2%80%94look> for any ongoing incidents under "Database" or your specific region (e.g., "US East 1"). If there’s a known outage or degradation, Supabase will list it here (and update when it’s fixed). Check the Supabase Community Forum (https://github.com/supabase/supabase/discussions) or Discord (https://discord.com/invite/supabase)—search<https://discord.com/invite/supabase)%E2%80%94search> for keywords like "query timeout" or your region + "unresponsive" to see if other users reported similar issues in the last 24 hours. If others are facing this, it’s likely a platform issue, and Supabase’s team will be addressing it. If not, we can focus on your database’s specific setup. 2. If it’s isolated to your database: Troubleshoot common "sudden timeout" causes (even with small data growth) A 50k record increase (450k→500k) shouldn’t cause timeouts on basic queries—here are the most likely culprits to check right now (all accessible via your Supabase Dashboard): A. Check for long-running "blocking queries" (the #1<#1> cause of sudden timeouts) Even a single stuck query can lock tables and block all other operations (e.g., a forgotten UPDATE without a WHERE clause, or a complex join that’s been running for hours). Go to your Supabase Dashboard → Database → Query Editor → Active Queries (or "Running Queries"—location varies by region). Look for queries that have been running for >5 minutes (or longer than usual). If you find any, terminate them (there’s a "Kill Query" button) and test your SELECT COUNT() again. B. Verify your database’s resource limits (did you hit CPU/memory constraints?) Supabase’s free/Pro tiers have resource limits (e.g., CPU usage, connection count). Even small traffic spikes can push you over limits, causing timeouts: Go to Supabase Dashboard → Settings → Billing & Usage → Usage—check if you’ve hit 100% CPU, memory, or "Database Connections" in the last 24 hours. If you’re on the Free tier: Note that it has strict CPU limits (for burst usage). If you saw a small traffic jump yesterday, it might have exhausted resources (even if data size is small). Upgrading to Pro (temporarily, for testing) can confirm if this is the issue. C. Check table indexes (did a missing/index issue break after data growth?) While you mentioned ANALYZE eventually succeeded, a missing or outdated index can make even COUNT() slow on 500k records (though timeout is extreme—this is more of a "double-check" step): For the job_openings table: Run \d job_openings in the Query Editor to list indexes. If you frequently query/filter by columns (e.g., status, location), ensure there’s an index on those columns. If indexes exist: Run REINDEX TABLE job_openings; (this may take time, but it fixes corrupted indexes that can cause unexpected slowdowns). 3. If none of the above works: Escalate to Supabase Support immediately Since this is a critical outage, don’t wait—Supabase’s support team can access infrastructure-level logs you can’t: Go to Supabase Dashboard → Support → Open a Ticket (or use the "Help" button in the bottom-right). Include these details to speed up resolution: Your Supabase project ID (found in Settings → General). The exact region of your database (e.g., "eu-west-1"). Screenshots of timeouts (e.g., the SELECT COUNT(*) error message) and resource usage (CPU/memory from Billing & Usage). Timeline recap (4 months stable → yesterday 450k → today 500k timeout → reduced to 400k still broken). Supabase’s team prioritizes critical database outages, so this will get you faster help than waiting for forum replies. I’ll keep an eye on this thread—if you find out it’s a platform issue (or fix it with one of the steps above), feel free to update here to help other users! Hope you get this resolved soon. — Reply to this email directly, view it on GitHub<#38172 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AQ3Z2BQMO6STNTFZLCCKIV33PLP57AVCNFSM6AAAAACEXEMACWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIMRQHEYTKMA>. You are receiving this because you authored the thread.Message ID: ***@***.***>