Supabase "canceling statement due to statement timeout", explained

The page in your app loads its list, the spinner turns for a few seconds, and then nothing. In the browser console, or in a red notice your builder added, there is one line:

canceling statement due to statement timeout

You open the same table in Supabase and every row is there. Ask the builder you made the app with (Lovable, Bolt, v0, Cursor, Claude Code or Replit) which query that page runs, paste it into the SQL Editor, and it comes back in a moment.

The advice you will find first for "canceling statement due to statement timeout" in Supabase is to raise the limit. That limit is doing its job, and every visitor to your app shares it. Before you raise anything, look at the Row Level Security policy on that table, the rule Postgres checks before it hands over each row. In Supabase's own measurements, that rule is where a query that should take 7 milliseconds spends 11 seconds.

What does "canceling statement due to statement timeout" mean in Supabase?

Postgres, the database inside your Supabase project, stopped the query because it ran longer than the role that sent it is allowed, and undid whatever the query had done.

The sentence comes from Postgres itself, with the error code 57014, which Postgres names query_canceled. Supabase hands it to your app unchanged, so the error your code receives carries code: '57014' and that sentence as its message. Postgres uses the same code for canceling statement due to user request, which is a cancellation somebody asked for, so the sentence tells you more than the number.

Picture your database as a library with a desk and a kitchen timer. Each time a visitor asks for books, the librarian sets the timer before going to the shelves, and how long it runs depends on who is asking. When it rings, every book goes back on the shelf and the visitor gets a slip with this sentence on it. If the request was to change something, the change is put back too.

Why does the query work in the SQL Editor and fail in my app?

Because the SQL Editor asks as a different visitor, one with no timer of its own and no rules to check.

Every request reaches Postgres under a role, a name that decides what the request may do. Supabase's timeouts guide lists the limit each role starts with:

The editor's role has a second advantage. Supabase's Row Level Security guide says that on Supabase postgres has bypassrls, the Postgres attribute that skips every policy. So the editor answers without reading a single rule. Your app's request reads every policy on the table against every row it looks at, with a timer that rings at three seconds for a visitor who is not signed in. The editor timed a different query from the one your app sends.

In the library you are staff. You walk into the stacks with no timer, and nobody checks a card. The visitor gets three seconds, and the librarian checks the rules against every book on the way.

Find the query that was cancelled

Search your project's Postgres logs for the words statement timeout, and note which role sent the query.

Supabase's timeouts guide gives a query for this. In the dashboard, open Explorer, choose Run SQL, set the source to Logs, pick a time range that covers the failure, and run this shortened version of it:

select timestamp,
       log_attributes['parsed.user_name'] as user_name,
       log_attributes['parsed.query'] as query
from logs
where source = 'postgres_logs'
  and match(event_message, 'statement timeout')
order by timestamp desc
limit 100;

A user_name of authenticator means the request came through the Data API, the server every supabase.from(…) call in your app goes through. The guide's table of roles lists authenticator as PostgREST, which is that server. The query column is the SQL your app's request turned into, and the table name in it is the table to look at.

The dashboard's Query Performance page is the other place people look, and the guide warns that it lists only slow queries that finished. A cancelled query is in the logs.

If the logs show cancellations on every table at once, the slow part is not one policy, and telling a Supabase outage from a problem in your app is the place to start.

Time it the way your app runs it

Run the query as your app's role with explain analyze in front, and Postgres prints how long it took and how many rows the policy turned away.

This is the method in Supabase's guide to Row Level Security performance, inside begin and rollback so the role change ends with the block. Copy a real user id from Authentication → Users in place of the zeros:

begin;
set local role authenticated;
set local request.jwt.claims to '{"role":"authenticated", "sub":"00000000-0000-0000-0000-000000000000"}';
explain analyze select * from public.orders;
rollback;

Two lines of the output matter. Execution Time is the number to hold against 3 and 8 seconds. Rows Removed by Filter counts the rows Postgres read and the policy refused, and Supabase's guide calls it the signal to watch: a policy that removes most of the table on every read is a policy whose filter column needs an index.

To time what a visitor who is not signed in gets, write set local role anon; and leave out the claims line.

The same guide suggests running the query once with Row Level Security on and once with it off, to see whether the policy is the cost. It also says to do that only outside production, because switching it off exposes every row. On a live app, time the policy against its rewritten version instead.

How can a policy cost seconds?

Postgres checks the policy against every row the query reads, and a function call in the policy runs again for every one of those rows.

Supabase published timings for this, measured on a table of 100,000 rows. Four of them, the slow way and the fast way:

The first two are slow and still inside three seconds on that table. The last two are past every limit an app request has. A helper function that reads a second table, the kind people write to check whether somebody is an admin, is called once for each row of the first, so on that table it read the second one 100,000 times.

In the library, that helper is the librarian walking to the front office to ask whether you are staff, once for every book on the shelf. Wrapping it in (select …) is asking once and writing the answer on the slip.

Supabase's Performance Advisor catches part of this. Its rule named Auth RLS Initialization Plan reports a policy that "re-evaluates current_setting() or auth.() for each row". A helper of your own, such as is_admin(), is outside that description, so an advisor page with nothing on it has not checked your helpers. Read the policies on the table yourself for any function call that is not wrapped.

Fix it in this order

Wrap the function calls, index the column the policy compares, then name the role. Each one is a short piece of SQL you can run in the editor or paste to your builder.

1. Wrap every function call in (select …).

alter policy "read own orders" on public.orders
  using ( (select auth.uid()) = user_id );

alter policy keeps the policy's name and its role and replaces the condition. Use your policy's name and your table's column, and do the same to a helper: (select private.is_admin()). Supabase attaches one condition: it only works for a value that stays the same from row to row. Why the brackets matter is in the guide to enabling Row Level Security, and a helper written to clear an infinite recursion error is exactly the kind that needs them.

2. Index the column the policy compares.

create index orders_user_id_idx on public.orders (user_id);

Supabase's guide adds a catch. A column counts as indexed only when it comes first in the index, so a table whose primary key is (team_id, user_id) has no index on user_id. On a large table that is being written to while you work, the Postgres documentation says a plain create index locks the table against writes until it is built. create index concurrently builds it without that lock, and it has to run as a statement on its own, outside a transaction.

3. Name the role the policy is for. A policy written to authenticated is never run for a visitor who is not signed in. In Supabase's timings, a signed-out request against a policy with no to took 170 ms, and with to authenticated it took under 0.1 ms.

4. Filter in the request as well. A policy works like an invisible where on every query, and Supabase's guide recommends repeating it in your app's request, .eq('user_id', userId), because Postgres can plan a faster query with it. In their timings that took a query from 171 ms to 9.

5. Take the join out of a team policy. A policy that matches each row against a membership table runs that lookup per row:

using ( (select auth.uid()) in (
  select user_id from team_user where team_user.team_id = projects.team_id
) )

Supabase's guide rewrites it to read the teams once and compare against that list:

using ( team_id in (
  select team_id from team_user where user_id = (select auth.uid())
) )

Then run the explain analyze from earlier again, and compare Execution Time and Rows Removed by Filter with what you had before.

Should I raise the statement timeout?

Only for a query you have measured, rewritten and still need, and then for that one function rather than for a whole role.

The limits are deliberate. Supabase's import guide says it enforces them "to ensure fair resource allocation and prevent long-running queries from affecting the overall system". The anon limit is shared by every visitor who is not signed in, and anyone can send that request with the publishable key that ships in your app. Raising it from three seconds to thirty gives each of those requests thirty seconds of your database.

When a job really does take longer, give the limit to the function that runs it. Supabase's guide describes this for "recurring functions that need a special exemption for runtimes", and it works for a function your app calls with supabase.rpc(…):

alter function public.monthly_totals() set statement_timeout to '20s';

If you do change a role, the guide's commands are alter role authenticated set statement_timeout = '15s'; and then notify pgrst, 'reload config';, so the Data API picks the new value up. Supabase caps queries from its client libraries at 60 seconds whatever you set.

Two fixes that stop the message and open the table

Switching Row Level Security off on the table, and sending the request with the secret key. Both make the query fast because both skip the policy, and both hand the rows to people you never meant to have them.

Switching it off. With no policy to run, nothing is checked per row and the timeout goes away. Supabase prints its own caution beside the test that suggests it: disabling Row Level Security exposes every row in the table to any role with a matching grant. Its guide also says that on existing projects a new table in public starts with select, insert, update and delete granted to anon, the role of a visitor who is not signed in. With the policy gone, those grants are all that stands between that visitor and the table.

The secret key. Supabase's guide says the service_role role behind it has bypassrls as well, so no policy runs. That key belongs on a server, and one sent from the browser is a key anyone can read out of your site; which keys are safe in a frontend goes through the pair. It does not buy much time either, because the guide gives service_role the same 8 seconds as authenticator.

Whether any table of yours answers a request carrying no login at all is one of the nine checks in Reeve's free scan. It reads your live site the way a visitor does, takes about 20 seconds and needs no account.

Keeping the policy quick and the table closed

A policy you fixed today has a next version. Your builder writes policies whenever a feature needs one, so the next rule it writes can call a function per row again, or open the table to make a screen load.

Reeve Monitor checks your app from outside, every hour:

• all nine checks every hour, including whether any table answers a request with no login
• whether the app is up, every 60 seconds
• a message when a result changes, so a table that starts answering strangers does not wait for you to look
• a monthly report of what it saw

Reeve Care keeps a copy of your Supabase database from before you changed it:

• an encrypted copy on a schedule, kept on Reeve's own storage in the EU, outside your Supabase account
• each copy verified before it counts, by counting the rows in every table
• a one-click restore that saves what is there now before it replaces anything
• your uploaded files as well, once you connect a Storage credential
• everything Monitor does

What to do today

Start with the table behind the page that failed. If it has no policies of its own yet, enabling Row Level Security on every table has the three shapes most tables need.