Timeouts
Extend database timeouts to execute longer transactions
Requests made through the Supabase API and Dashboard have a timeout of 60 seconds. The database also has a global default timeout of 2 minutes.
To execute longer transactions, connect to your database using Supavisor or the direct connection string, and change the timeout settings.
Change Postgres timeout
You can change the Postgres timeout at the:
Session level
Session level settings persist only for the duration of the connection.
Set the session timeout by running:
_10set statement_timeout = '10min';
Because it applies to sessions only, it can only be used with connections through Supavisor in session mode (port 5432) or a direct connection. It cannot be used in the Dashboard, with the Supabase Client API, nor with Supavisor in Transaction mode (port 6543).
This is most often used for single, long running, administrative tasks, such as creating an HSNW index. Once the setting is implemented, you can view it by executing:
_10SHOW statement_timeout;
See the full guide on changing session timeouts.
Function level
This works with the Database REST API when called from the Supabase client libraries:
_10create or replace function myfunc()_10return void as $$_10 select pg_sleep(3); -- simulating some long-running process_10$$_10language_10set statement_timeout TO '4s'; -- set custom timeout
This is mostly for recurring functions that need a special exemption for runtimes.
Role level
This sets the timeout for a specific role.
The default role timeouts are:
anon
: 3sauthenticated
: 8sservice_role
: none (capped by API to be 60s)postgres
: none (capped by default global timeout to be 2min)
Run the following query to change a role's timeout:
_10alter role example_role set statement_timeout = '10min'; -- could also use seconds '10s'
Unlike global settings, the result cannot be checked with SHOW statement_timeout
. Instead, run:
_12select_12 rolname,_12 rolconfig_12from pg_roles_12where_12 rolname in (_12 'anon',_12 'authenticated',_12 'postgres',_12 'service_role'_12 -- ,<ANY CUSTOM ROLES>_12 );
Global level
This changes the statement timeout for all roles and sessions without an explicit timeout already set.
_10alter database postgres set statement_timeout TO '4s';
Check if your changes took effect:
_10show statement_timeout;
Although not necessary, if you are uncertain if a timeout has been applied, you can run a quick test:
_10create or replace function myfunc()_10returns void as $$_10 select pg_sleep(601); -- simulating some long-running process_10$$_10language sql;
Identifying timeouts
The Supabase Dashboard contains tools to help you identify timed-out and long-running queries.
Using the Log Explorer
Go to the Log Explorer, and run the following query to identify timed-out events (statement timeout
) and queries that successfully run for longer than 10 seconds (duration
).
_20select_20 cast(postgres_logs.timestamp as datetime) as timestamp,_20 event_message,_20 parsed.error_severity,_20 parsed.user_name,_20 parsed.query,_20 parsed.detail,_20 parsed.hint,_20 parsed.sql_state_code,_20 parsed.backend_type_20from_20 postgres_logs_20 cross join unnest(metadata) as metadata_20 cross join unnest(metadata.parsed) as parsed_20where_20 regexp_contains(event_message, 'duration|statement timeout')_20 -- (OPTIONAL) MODIFY OR REMOVE_20 and parsed.user_name = 'authenticator' -- <--------CHANGE_20order by timestamp desc_20limit 100;
Using the Query Performance page
Go to the Query Performance page and filter by relevant role and query speeds. This only identifies slow-running but successful queries. Unlike the Log Explorer, it does not show you timed-out queries.
Understanding roles in logs
Each API server uses a designated user for connecting to the database:
Role | API/Tool |
---|---|
supabase_admin | Used by Supabase to configure projects and for monitoring |
authenticator | PostgREST |
supabase_auth_admin | Auth |
supabase_storage_admin | Storage |
supabase_realtime_admin | Realtime |
supabase_replication_admin | Synchronizes Read Replicas |
postgres | Supabase Dashboard and External Tools (e.g., Prisma, SQLAlchemy, PSQL...) |
Custom roles | External Tools (e.g., Prisma, SQLAlchemy, PSQL...) |
Filter by the parsed.user_name
field to only retrieve logs made by specific users:
_10-- find events based on role/server_10... query_10where_10 -- find events from the relevant role_10 parsed.user_name = '<ROLE>'