Canceling statement due to statement timeout

What you see

ERROR:  57014: canceling statement due to statement timeout

Through the Data API it comes back as HTTP 500:

{ "code": "57014", "details": null, "hint": null, "message": "canceling statement due to statement timeout" }

It can also show up in Studio's SQL editor, in a migration, or in a cron job's entry in cron.job_run_details.

Why it happens

statement_timeout is a Postgres setting that cancels any single statement that runs longer than the limit. It protects the database from runaway queries that hold connections and locks. Timeouts are usually attached to roles, so the limit depends on who runs the query: requests from your app run as anon or authenticated, while Studio, the SSH tunnel and cron jobs run as postgres.

The query is either genuinely slow (a missing index, a big table scan, an RLS policy that does work per row) or doing a job that's meant to take a while, like a backfill.

How to fix it

1. Check which timeouts apply. SupaHost doesn't set its own; the values come from the Supabase Postgres image, so look rather than assume:

   select rolname, rolconfig
   from pg_roles
   where rolname in ('anon', 'authenticated', 'service_role', 'authenticator', 'postgres');
   
   show statement_timeout;  -- the value for your current session
   

2. Make the query faster first. Run it with explain analyze and look for sequential scans on large tables:

   explain analyze
   select * from public.bookings
   where venue_id = 42 and starts_at >= now()
   order by starts_at
   limit 50;
   

   An index on the filtered columns often turns seconds into milliseconds:

   create index concurrently if not exists bookings_venue_starts_idx
     on public.bookings (venue_id, starts_at);
   

3. For a one-off long job in the SQL editor or psql, raise the limit for that session only:

   set statement_timeout = '15min';
   update public.bookings set status = 'archived' where starts_at < now() - interval '2 years';
   

   In a cron job, put the set at the start of the job's SQL. Each statement in the command gets its own timer, so the setting applies to the statements after it.

4. If an API role's limit is too low for legitimate requests, raise it for that role and tell the Data API to reload its config:

   alter role authenticated set statement_timeout = '15s';
   notify pgrst, 'reload config';
   

   Keep API timeouts short. A long timeout on anon lets anyone tie up your connections with slow requests.

5. Big batch work is better split into chunks (for example 5,000 rows per statement) than run as one huge statement.

On SupaHost

• Each project's Data API has a pool of 5 database connections. A few requests stuck on slow queries can make every other request for that project wait, and they may fail with PGRST003 (timed out waiting for a connection) instead. Fixing the slow query fixes both.
• All projects on an instance share one VM, so a slow query in one project uses CPU the others need. To see what's running across the instance, use the queries in High CPU usage on your instance.
• Studio opens from Dashboard → your project → Database tab → Open Studio (owner only).

Related

• Connections and timeouts
• Speeding up slow queries with indexes
• Query performance and EXPLAIN
• RLS performance best practices