Fix Lovable Supabase Errors: supabaseUrl is required, Permission Denied, and Failed to Fetch

Which Supabase error do I actually have?

Start by matching the exact error string in your browser console or build log to one of the four common Lovable Supabase failures. Each has a distinct cause and a distinct fix — treating them as one generic 'Supabase broke' problem is what sends builders into the Bug Doom Loop, spending credits re-prompting when the real fix is a one-line config or policy change.

Open DevTools (F12) and read the Console tab first. Supabase errors are specific: they name a missing variable, a denied schema, a network failure, or a hung promise. Copy the verbatim string before doing anything else — the wording tells you whether the problem is a missing env var, a Row Level Security policy, an auth-listener mistake, or a CORS/network block.

The table below is the diagnostic map. Find your symptom in the first column, confirm the cause in the second, and jump to the matching section for the copy-paste fix.

Related: Backend & Database troubleshooting hub · Lovable RLS permission errors

Which Postgres or PostgREST code came back?

Supabase returns a code with every error, and the code is more searchable than the message. PostgREST forwards Postgres SQLSTATE codes untouched and adds its own PGRST-prefixed codes for problems that never reached the database. The index below maps the codes a Lovable app actually hits to the HTTP status they arrive as and the fix that clears them.

Read the code before the prose. PostgREST error bodies follow the PostgreSQL error structure — message, details, hint and errcode — so the body already contains the identifier you should be searching for. A message can be reworded between versions; a code cannot.

Two of these codes belong to pages of their own on this site because they are whole failure modes rather than single errors. 42P17 is what a policy that queries its own table produces, and 42501 is the surface form of an RLS permission problem rather than a missing grant in most Lovable projects.

What does PGRST116 mean?

PGRST116 arrives as HTTP 406, and PostgREST's own reference states the condition exactly: more than one or no items were returned when a singular response was requested. The row count did not match the shape the client asked for. In a Lovable app the usual reason is not a bug in the query — it is a Row Level Security policy filtering the row out before it is counted.

That distinction decides the fix. If the row genuinely does not exist, the code is correct and the client is wrong to demand exactly one — stop requesting a singular response and handle the empty case. If the row does exist but the signed-in user cannot see it, the query is right and the policy is wrong, and no client change will help.

Tell the two apart in one step: run the same select in the Supabase SQL editor, where you are the owner and RLS does not filter you. A row that appears there and not in your app is a policy problem. A row that appears in neither never existed, and the insert that was supposed to create it is the real failure.

1. Copy the failing query and run it as a plain select in the Supabase SQL editor.
2. If it returns a row there, open the table's policies and check the USING expression against the signed-in user's id.
3. If it returns nothing there, trace the insert that should have created the row — the write failed earlier and silently.
4. Only once you know which of the two it is, change either the policy or the read, never both at once.

What does 23505 duplicate key mean?

23505 is the Postgres uniqueness violation, and PostgREST returns it as HTTP 409 Conflict. Something tried to insert a value a unique constraint or primary key already holds. PostgREST forwards the full Postgres error structure — message, details, hint and code — so the response body itself tells you which constraint you collided with. Read those fields before you change any code.

In Lovable projects this most often means the same row is being created twice by two different mechanisms. A generated client-side insert and a database trigger can both try to create the same profile row after signup, and whichever runs second gets 23505. The duplicate is not a race condition to retry around — it is two owners for one write, and the fix is to pick one.

The other common source is a unique constraint the generator added for you and you never saw. If the constraint name in the error body is one you do not recognise, inspect the table definition before assuming the data is wrong: the row may be legitimate and the constraint may be the thing that does not match how the feature actually works.

How do I fix 'supabaseUrl is required'?

This error means createClient() ran with an undefined URL — the VITE_SUPABASE_URL environment variable is missing or misnamed in the environment where the app is running. It is almost always a deployment gap: the variable exists in the Lovable editor but was never added to your hosting provider's environment panel, so the production bundle initializes the client with undefined.

Vite inlines env vars at build time, and only variables prefixed with VITE_ are exposed to the browser. If you renamed the variable, dropped the VITE_ prefix, or set it only in the editor and not on Vercel, Netlify, or Cloudflare, the production build has nothing to read. This is The Vanishing Env-Var: the app works in preview, then breaks the moment it deploys.

1. Confirm the exact names your client expects — usually VITE_SUPABASE_URL and VITE_SUPABASE_ANON_KEY.
2. Copy the Project URL and anon public key from Supabase: Project Settings to API.
3. Add both variables to your hosting provider's environment settings panel (not just the Lovable editor).
4. Trigger a fresh deploy so Vite re-inlines the values — env var changes do not apply to an existing build.
5. Open the deployed pop-out build and confirm the console no longer shows the error.

Related: Env vars vanish on deploy · Lovable secrets best practices

Why does Supabase say 'permission denied for schema public'?

Your query reached Supabase, but the database rejected it. With Row Level Security enabled and no policy granting the current role access, Postgres denies the request by default. The error names the schema (public) because the anon or authenticated role has no policy permitting the operation you attempted — RLS denies everything until you explicitly allow it.

Lovable enables RLS on tables it creates, which is correct for security but means a table with no policies returns nothing and errors on writes. A related variant — 'new row violates row-level security policy' — means a SELECT policy exists but no INSERT policy with a WITH CHECK clause permits the write. Each operation (select, insert, update, delete) needs its own policy.

Write policies that scope rows to the signed-in user with auth.uid(). A blanket 'allow all' policy makes every user's data readable by every other user — a misconfiguration that exposes private records. Fix the permission error and the data-isolation risk in the same change.

1. In Supabase, open Authentication to Policies and select the affected table.
2. Add a SELECT policy: 'USING (auth.uid() = user_id)' so users read only their own rows.
3. Add an INSERT policy with 'WITH CHECK (auth.uid() = user_id)' so writes are scoped too.
4. Re-run the failing query as a signed-in user and confirm it returns data without the denied error.

Related: fix RLS infinite recursion (42P17) in Lovable

Why does my app freeze after login (onAuthStateChange deadlock)?

If the UI hangs right after sign-in, you are likely calling another Supabase query directly inside the onAuthStateChange callback. The Supabase client serializes auth events, so an awaited query made inside the listener waits for the lock the listener itself holds — a deadlock. The await never resolves, and your loading state spins forever.

This is one of the most common Supabase patterns Lovable generates incorrectly. The callback should update state synchronously and defer any follow-up Supabase call so it runs outside the lock. Wrapping the query in setTimeout(..., 0) pushes it to the next tick, after the auth event has released its lock.

A frozen screen is only one of the shapes this takes. If the sign-in never completes in the first place — Google OAuth bouncing back, no confirmation email arriving, or a password-reset link that lands on the wrong origin — the deadlock is not your problem, and our walkthrough for Lovable auth login not working covers the Site URL and redirect allow-list settings those failures come from.

1. Find your supabase.auth.onAuthStateChange listener (usually in an auth context or App root).
2. Move any await supabase.from(...) or supabase.auth.getUser() call out of the callback body.
3. Wrap the deferred call in setTimeout(() => { /* fetch profile, etc. */ }, 0).
4. Keep only synchronous state updates (setSession, setUser) inside the callback itself.
5. Sign out and sign in again to confirm the UI no longer hangs after authentication.

What causes 'Failed to fetch' when calling Supabase?

'TypeError: Failed to fetch' means the request never reached Supabase at all — it failed before the server could respond. The four usual causes are a wrong or undefined project URL, a paused or deleted Supabase project, a CORS block on a custom domain, or the browser simply being offline. Because it is a network-layer failure, the body of the response is empty.

Open the Network tab in DevTools and click the failed request. A status of '(failed)' or 'CORS error' points to origin or URL problems; a request that never appears at all points to an undefined URL (often the same root cause as 'supabaseUrl is required'). A 401 or 403 that does return is not Failed to fetch — that is an auth or RLS problem, covered above.

Check the Supabase dashboard: a project on the free tier that paused after inactivity will reject every request until you resume it. And if your app runs on a custom domain, confirm that origin is allowed — Supabase rejects requests from origins it does not recognize.

1. Verify VITE_SUPABASE_URL resolves to your real project URL (open it in a browser — it should return JSON, not an error).
2. In the Supabase dashboard, confirm the project is active and not paused.
3. If on a custom domain, check the Network tab for a CORS error and confirm your origin is permitted.
4. Test from a normal network — a corporate proxy or VPN can block the Supabase domain outright.

How do I tell a config error from a code error?

Config errors break in production but work in the editor; code errors break in both. 'supabaseUrl is required' and most 'Failed to fetch' cases are config — the bundle is missing values or pointing at the wrong project. 'permission denied', RLS violations, and the auth-listener deadlock are code-and-policy errors that reproduce everywhere because the logic itself is wrong.

Use the pop-out deployed build as your test. If the error appears only in the deployed build and not the editor preview, it is almost certainly an environment or deployment gap — a missing env var or a stale build. If it appears in both, the problem is in your code or your Supabase policies, and adding env vars will not help.

This distinction saves credits. Re-prompting Lovable to 'fix the Supabase error' will never solve a missing production env var, because the editor that the AI sees already has the value. The AI cannot see your hosting provider's environment panel — only a human checking the deploy target can close that gap.

When should I get a human to fix Supabase errors?

If you have matched your error to the table, applied the fix, and it still fails — or if the same error returns after every revert — the root cause is structural. Tangled RLS policies, a client initialized in the wrong place, or env vars that disagree between editor and host are quick for a senior engineer to trace and slow to fix by re-prompting.

Escalate when: the permission error persists after adding policies (often a deeper RLS recursion or a missing GRANT); the deadlock reappears because auth state is managed in multiple places; or you have spent more than a handful of credits re-prompting the same Supabase error. A specialist reads your actual client setup and policies, fixes the exact cause, and leaves you a written explanation — usually cheaper than continued guessing.

Related: emergency Lovable rescue · Book an emergency audit call