"Database error saving new user": find and fix the broken trigger

Why one broken trigger blocks every signup

A row inserted into auth.users is one transaction. If a trigger on that table (for example, a handle_new_user function that copies the new row into a public.profiles table) raises an error, Postgres rolls back the whole transaction, including the Auth row — so the signup fails for every user, not just one, until the trigger is fixed.

Sources: Supabase: Database error saving new user

Find the real error

1. Step 1

   Check the Auth logs first

   In the dashboard, open the Auth Logs explorer around the time of the failed signup. It confirms the request reached the database layer and failed there rather than at validation.

2. Step 2

   Then check the Postgres logs

   The Postgres Logs explorer has the actual error the trigger raised. A common one is a relation does not exist error, which means the trigger inserts into a table (often profiles) that was renamed, dropped, or never created in this environment.

Sources: Supabase: Database error saving new user

The fix: make the destination table match the trigger, or fix the trigger

• If the referenced table is missing, create it with the columns the trigger inserts (or run the migration that was supposed to create it).
• If the table is not actually needed, remove the insert from the trigger function on the Database Functions page instead of leaving a dangling reference.
• Either way, the trigger function should be security definer with search_path set to an empty string, so it runs with a predictable schema path regardless of who signs up.

create function public.handle_new_user()
returns trigger
language plpgsql
security definer set search_path = ''
as $$
begin
  insert into public.profiles (id, first_name, last_name)
  values (new.id, new.raw_user_meta_data ->> 'first_name', new.raw_user_meta_data ->> 'last_name');
  return new;
end;
$$;

create trigger on_auth_user_created
  after insert on auth.users
  for each row execute procedure public.handle_new_user();

Sources: Supabase: Managing user data

On Scribase

Scribase runs the same auth.users table and trigger model, so an existing handle_new_user function moves over unchanged with the importer's schema step — it is worth testing one signup right after a move for the same reason: a trigger pointed at a renamed table fails the same way on any Postgres.

Sources: Scribase pricing