Database Webhooks fail: "schema supabase_functions does not exist" even with pg_net enabled

[dipo-ai]

Hi,

I'm trying to create a Supabase Database Webhook for an appointments table, triggering on INSERT and UPDATE and calling a deployed Edge Function.

When I create the webhook from the Supabase Dashboard, I get:

ERROR: 3F000: schema "supabase_functions" does not exist

The project has pg_net enabled and the net schema is present, but the supabase_functions schema is missing.

What I am trying to configure

• Table: appointments
• Events: INSERT and UPDATE
• DELETE: disabled
• Webhook type: Supabase Edge Function
• Edge Function: notify-appointment-change
• HTTP method: POST

The Edge Function is already deployed and works independently.

What I checked

1. pg_net is enabled on the project.
2. The net schema exists.
3. The supabase_functions schema does not exist.
4. Retrying the Database Webhook creation from the Dashboard produces the same error.
5. I have not created a custom supabase_functions schema or custom SECURITY DEFINER workaround.

This appears to happen during the Dashboard's Database Webhook provisioning itself, before the webhook can be created.

I also found reports/issues describing the same supabase_functions schema error.

I have opened a Supabase Support ticket for the same project as well: SU-468550.

Environment

• Supabase project region: Central EU (Frankfurt)
• Plan: Free
• Database Webhook created through the Supabase Dashboard
• Edge Function deployment works
• pg_net is enabled

Is there currently a known issue with Database Webhook provisioning / the supabase_functions schema?

If so, is there an official workaround or is this something that needs to be fixed on the Supabase platform side?

Thanks!

[k1ng-arthur]

Have you turned on Database Webhooks in the integration section https://supabase.com/dashboard/project/_/integrations/webhooks/overview

[wonjangcloud9]

pg_net and Database Webhooks are provisioned separately, which is why the checks you ran all look correct.

• Enabling pg_net gives you the net schema only.
• The supabase_functions schema and supabase_functions.http_request() — the trigger function every Dashboard webhook points at — are created when the Database Webhooks integration itself is enabled on the project, not by pg_net.

So net existing while supabase_functions is missing is the expected state for a project where that integration was never turned on. Enable it at Dashboard → Integrations → Database Webhooks → Enable (older dashboards: Database → Webhooks → Enable webhooks), then create the webhook.

You can confirm the before/after state without changing anything:

select nspname from pg_namespace where nspname in ('net', 'supabase_functions');

select n.nspname, p.proname
from pg_proc p join pg_namespace n on n.oid = p.pronamespace
where n.nspname = 'supabase_functions';

After enabling, the second query should return supabase_functions.http_request. If it doesn't, provisioning genuinely failed on the project and you can't fully self-heal it: you can create schema supabase_functions, but http_request() is owned by supabase_admin, so recreating it with the right ownership isn't something a project-level role can do. That's the case where your support ticket (SU-468550) is the correct path — worth replying there with the output of the query above.

To unblock the Edge Function in the meantime, skip the wrapper and write the trigger against pg_net directly. This is essentially what the Dashboard generates:

create or replace function public.notify_appointment_change()
returns trigger
language plpgsql
security definer
as $$
begin
  perform net.http_post(
    url     := 'https://<project-ref>.supabase.co/functions/v1/notify-appointment-change',
    headers := jsonb_build_object(
                 'Content-Type', 'application/json',
                 'Authorization', 'Bearer ' || current_setting('app.settings.service_key', true)
               ),
    body    := jsonb_build_object(
                 'type', TG_OP,
                 'table', TG_TABLE_NAME,
                 'schema', TG_TABLE_SCHEMA,
                 'record', to_jsonb(new),
                 'old_record', case when TG_OP = 'UPDATE' then to_jsonb(old) end
               )
  );
  return new;
end;
$$;

create trigger appointments_webhook
after insert or update on public.appointments
for each row execute function public.notify_appointment_change();

Keep the service key out of the migration — read it from Vault or a database setting rather than inlining it. Delivery is async either way, so check net._http_response for the results of the calls.

[giaBaoJS]

Tracing this through the source, supabase_functions is created by the Database Webhooks enable step, never by pg_net. All file references are supabase/supabase at 26585dd unless stated.

What creates the schema

The dashboard decides whether webhooks are enabled purely by whether the schema exists, in packages/pg-meta/src/sql/studio/integrations/enable-webhooks.ts:8-12:

SELECT EXISTS (
  SELECT 1 FROM information_schema.schemata
  WHERE schema_name = 'supabase_functions'
) AS schema_exists;

The enable script in the same file is what creates it, at line 125:

CREATE SCHEMA supabase_functions AUTHORIZATION supabase_admin;

supabase_functions.http_request() is created at line 153 of that file, and line 235 sets its owner:

ALTER function "supabase_functions".http_request() OWNER TO supabase_functions_admin;

So the trigger function is owned by supabase_functions_admin, not by supabase_admin; only the schema is authorized to supabase_admin. The file header records that it is copied from the Management API's project-database-webhooks.service.ts, so this is the SQL the platform actually runs.

Note the direction of the dependency: the enable script itself runs CREATE EXTENSION IF NOT EXISTS pg_net SCHEMA extensions at line 122. Enabling webhooks provisions pg_net. Enabling pg_net does not provision webhooks.

Why supabase_functions_admin existing proves nothing

That role is created by the pg_net event trigger in the base image, independently of webhooks. supabase/postgres, migrations/db/init-scripts/00000000000003-post-setup.sql:60-67:

IF NOT EXISTS (SELECT 1 FROM pg_roles WHERE rolname = 'supabase_functions_admin')
THEN
  CREATE USER supabase_functions_admin NOINHERIT CREATEROLE LOGIN NOREPLICATION;
END IF;

That block runs inside extensions.grant_pg_net_access(), wired to the issue_pg_net_access event trigger on CREATE EXTENSION at line 95 of the same file (repeated in migrations/db/migrations/20250220051611_pg_net_perms_fix.sql:15-22). On your project the role is almost certainly present while the schema is absent, so do not read its presence as a sign that provisioning ran.

Where the 3F000 comes from

The dashboard builds a webhook as an ordinary trigger pointing at function_schema: 'supabase_functions' (apps/studio/components/interfaces/Database/Hooks/EditHookPanel.tsx:242). CREATE TRIGGER ... EXECUTE FUNCTION supabase_functions.http_request(...) against a missing schema raises exactly 3F000. The failure is at trigger creation, not during enable, which means the enable step never ran on this project.

Check the current state

-- 1. the dashboard's own "is it enabled" check
select exists (
  select 1 from information_schema.schemata
  where schema_name = 'supabase_functions'
) as webhooks_enabled;

-- 2. the trigger function and its owner
select n.nspname, p.proname, pg_get_userbyid(p.proowner) as owner
from pg_proc p join pg_namespace n on n.oid = p.pronamespace
where n.nspname = 'supabase_functions';

-- 3. pg_net version and the schema its objects live in
select e.extname, e.extversion, n.nspname as ext_schema
from pg_extension e join pg_namespace n on n.oid = e.extnamespace
where e.extname = 'pg_net';

-- 4. expected to already exist, see above
select rolname from pg_roles where rolname = 'supabase_functions_admin';

Hosted: use the Enable action, and do not hand-roll the schema

Enabling is a platform endpoint, not SQL you can run: Studio posts to /platform/database/{ref}/hook-enable (apps/studio/data/database/hooks-enable-mutation.ts:13). The prompt carrying that action renders on Integrations > Database Webhooks only while the schema is missing and disappears once it exists (apps/studio/components/interfaces/Integrations/Webhooks/OverviewTab.tsx:30 and :64).

Running the enable SQL yourself will not work either. Line 125 creates the schema AUTHORIZATION supabase_admin; the SQL Editor executes as postgres (apps/docs/content/guides/database/postgres/roles.mdx:128) and supabase_admin is documented as an internal Supabase role (same file, line 130). Inference from there, since Postgres requires membership in a role to create an object owned by it: postgres cannot execute that statement.

One thing worth avoiding: do not work around this with a bare create schema supabase_functions. Line 125 has no IF NOT EXISTS and the whole script is a single transaction (BEGIN at line 17, COMMIT at line 262), so a pre-existing schema aborts the enable run and rolls back every object it would have created, while the check at lines 8-12 would then report webhooks as enabled. That converts a fixable state into a stuck one.

Self-hosted, for anyone arriving here from a search

The identical SQL ships as docker/volumes/db/webhooks.sql and is mounted at docker/docker-compose.yml:484 as /docker-entrypoint-initdb.d/init-scripts/98-webhooks.sql. Entrypoint init scripts run only when the data directory is first initialized, so a stack whose volumes/db/data predates that mount never gets the schema. Applying webhooks.sql as a superuser is the fix there.

Verdict

For a hosted project this is a missing provisioning step rather than a pg_net bug or an Edge Function problem, and it is expected that net exists while supabase_functions does not on a project where webhooks were never enabled. If the Enable action is offered and clicking it returns an error, that part is platform-side and SU-468550 is the right channel; the output of query 1 and 2 above is the useful thing to attach.