For builders shipping this week

"Database error saving new user" in a Lovable app? Check these 5 things

You signed up fine while building. Then a real person tries, and the form shows Database error saving new user, a red toast about new row violates row-level security policy, or the signup "works" and they land on an empty dashboard. Your own account never hits this, because it was created before the last database change, or you are signed in as the project owner.

Can a brand-new visitor actually create an account in your app? FirstUser is an AI test user for Lovable, Bolt and Cursor apps. It opens your published URL in a fresh browser, signs up with a new identity, logs in, and tells you which step failed, with a screenshot, a plain-English diagnosis and a fix prompt you can paste into Lovable. Run a free signup test — no account, no card.

The cause is almost always the step that runs right after Supabase creates the user: a trigger or an insert that fills your own tables. Supabase's own docs warn that if that trigger fails, it could block signups.

1. Does a trigger run on new users, and does it still match the table?

Many Lovable apps have a handle_new_user function that inserts a row into public.profiles (or users, accounts) whenever someone signs up. If you later renamed a column, made a column not null, or added a column without a default, the trigger's insert fails, and Supabase Auth reports it as Database error saving new user.

Open Supabase → Database → Functions, find the function the trigger calls, and compare its insert with the table's current columns. Every not null column needs a value or a default.

2. Is the trigger function allowed to write?

The trigger runs during signup, before the new user has a session. If the function is not security definer, row-level security on profiles can block its insert. Supabase's example uses security definer set search_path = '' and fully qualified table names like public.profiles. If your function lacks those, ask Lovable to recreate it that way.

3. Does the app insert the profile itself, from the browser?

Some generated code skips the trigger and calls insert on profiles right after signUp. When email confirmation is on, there is no logged-in session yet at that moment, so an RLS policy like "users can insert their own row" (auth.uid() = id) rejects it with new row violates row-level security policy. Either move the insert into a trigger, or do it after the first confirmed login.

4. Can a new user read their own rows?

If signup succeeds but the dashboard is empty or loads forever, check the select policies. RLS being "on" with no select policy means nobody can read anything. A policy that only matches your admin account, or a role column that new users don't get, has the same effect. Each table the first screen loads needs a policy that lets auth.uid() read its own rows.

5. Did you test with a brand-new address on the live site?

Re-using your own email, or an account you created with Add user in the dashboard, skips the exact path a stranger takes. Use a fresh address, a private window and the published URL. Then check Supabase → Logs → Auth and Postgres logs at the time of the attempt: the real error (missing column, policy violation, null value) is written there.

Paste-ready prompt for Lovable

New users can't sign up on my published app: they get "Database error saving new user" (or a row-level security error, or an empty dashboard). Check the handle_new_user trigger function against the current columns of every table it inserts into, make it security definer with set search_path = '' and fully qualified table names, remove any profile insert that runs in the browser before the user has a session, and list the RLS policies a brand-new user needs to read their own data on the first screen.

Test it like a first-time user

Your own account hides this bug, because it already exists. FirstUser opens your published URL as a new visitor, signs up with a fresh identity, logs in, and reports the step that broke with a screenshot and a fix prompt. Run the free signup test, or see plans for daily checks, so the next schema change doesn't quietly break signup again.

Run a free signup test