supabase-js v2 abortSignal cancels the HTTP request, but does PostgREST stop the running Postgres statement?

Short answer: no. In supabase-js v2, .abortSignal(signal) aborts the client-side fetch, so the pending promise rejects with an AbortError and the HTTP connection is torn down. It does not send a cancellation to PostgreSQL. The statement generally keeps running on the backend until it finishes, hits a server-side timeout, or is cancelled by an operator. Treat that as the expected shape of the behavior, but verify it on your own deployment before relying on it.

Confirmed vs. likely

Confirmed: the abort is a client and HTTP-layer concern. The promise settles and the socket closes. That is standard AbortController/fetch behavior.

Likely, but version- and deployment-dependent: PostgREST does not, on detecting a dropped client connection, issue a PostgreSQL CANCEL for the running statement. The backend session stays in pg_stat_activity with state active, holding its pooled connection and any locks it acquired. This is the behavior most commonly reported for hosted Supabase projects, but it is not something I can confirm for every PostgREST release or hosting configuration, so treat it as a hypothesis to test.

Verify it on your project

1. Create a throwaway function that sleeps:

   create or replace function test_abort()
   returns void language plpgsql as $$
   begin
     perform pg_sleep(30);
   end;
   $$;

2. Call it with an abort signal, for example supabase.rpc('test_abort').abortSignal(AbortSignal.timeout(1000)).
3. After the client promise has already rejected, inspect the backend from a separate SQL session:

   select pid, state, wait_event_type,
          now() - query_start as runtime, query
   from pg_stat_activity
   where query ilike '%test_abort%'
     and pid <> pg_backend_pid();

If a row stays active for the full 30 seconds after the client error, the statement was not cancelled. If it vanishes within a second or two, something in your stack is propagating the cancellation and it is worth finding out which layer. Note that pg_stat_activity.query shows the top-level statement text, and with a pooler in front the pid you observe may be a pooled backend rather than a per-request session.

A server-side ceiling is still worth setting

Because a client abort is not a reliable server-side resource control, add one. A per-role statement_timeout is the simplest lever and applies to every request made through that role:

alter role authenticated set statement_timeout = '10s';
alter role anon set statement_timeout = '5s';

For an endpoint that legitimately needs longer, scope the limit inside the function with set local statement_timeout rather than raising the role-wide value. Keep the client-side abortSignal as well: it releases the UI early, which is a real user-experience win, but it is a UX control rather than a backend kill switch.

One detail that changes the recommendation

Do your API requests go through a transaction-mode pooler (Supavisor or PgBouncer) or straight to Postgres? Under transaction pooling a long statement holds a server connection out of the pool for its whole duration, so a lower timeout matters more. On direct connections the blast radius is smaller. That detail is the one thing that would let me tighten the numbers.