QAlaunch

Lovable app shows no Supabase data: fixing Row Level Security

When a Lovable app shows an empty list even though the rows are in Supabase, Row Level Security is almost always the reason. With RLS enabled and no matching policy, Supabase returns an empty array rather than an error, so the page looks fine and simply has nothing in it. Add a policy per operation for the authenticated role, scoped to the signed-in user, and make sure new rows store that user's id. Never fix it with using (true) or the service role key in the browser.

Opens your site in a real browser on desktop and phone. Free, about two minutes, no signup. Full report from $19.

What you'll see

Dashboards, lists or tables on the published app show "No items yet" or render empty, while the Supabase Table Editor clearly shows rows. There is no error on screen. In DevTools the request to /rest/v1/ comes back 200 with [] as the body, or occasionally 401 or 403. Sometimes data appears for the person who built the app and not for anyone else.

Why it happens

1. RLS is on and no policy allows the read

Supabase's own troubleshooting page says an empty data array with rows in the table usually means RLS is enabled with no policy, or the request does not meet the policy. Lovable often enables RLS on new tables, which is correct, but the matching SELECT policy can be missing.

2. The request arrives without a user session

A policy built on auth.uid() only matches when the request carries the user's token. If the session was lost after a redirect, or the page fetches before login finishes, the query runs as anon and gets nothing back.

3. Rows were saved without the owner column

If inserts never set user_id, or there is no INSERT policy with a WITH CHECK clause, rows end up with a null owner or are never written. A correct SELECT policy then has nothing it is allowed to return.

4. A previous "fix" that opened everything

Sometimes the data shows up because someone added using (true) or put the service_role key in frontend code. The list works, but every visitor can now read every row, which is a far worse problem than an empty page.

How to fix it

  1. On the live site, log in, open DevTools > Network and filter by rest/v1. Click the request for the empty list and read the status and response body: 200 with [] points to policies, 401 or 403 points to a missing or rejected session.
  2. In the Supabase dashboard open Table Editor, select the table and check whether RLS is enabled, then open Authentication > Policies to see what exists for it. On Lovable Cloud projects the same information is under the project's Cloud database view.
  3. Check the rows themselves: does the owner column (often user_id) hold the id of the user who should see them? If it is empty, the inserts are the bug, not the reads.
  4. Add one policy per operation for the authenticated role, for example SELECT using ((select auth.uid()) = user_id) and INSERT with check ((select auth.uid()) = user_id). Add UPDATE and DELETE the same way only if the app needs them.
  5. If a table is meant to be public, such as a list of products, give it a SELECT policy for the anon role on that table only, and keep writes restricted.
  6. Search the code for service_role and for using (true). Remove both from anything that runs in the browser, and rotate the service role key in Supabase if it was ever shipped to the frontend.

Prompt to paste into Lovable

My [table name] data shows as empty on the published site for logged-in users. Check the Supabase Row Level Security policies on this table. Add SELECT, INSERT, UPDATE and DELETE policies for the authenticated role that only allow rows where user_id = auth.uid(), make sure every new row sets user_id to the current user, and make sure the page waits for the session before it queries. Do not use the service role key or "using (true)" anywhere in client code. Explain each policy you add.

How to check it's fixed

  • Log in on the live site in a private window and confirm the rest/v1 response contains your rows, not [] and not a 401.
  • Sign up as a second test user and check that you cannot see the first user's rows, even by changing an id in the URL.
  • Log out and reload: private data should no longer be returned in any network response.

What a QAlaunch scan shows for this

  • A public page that renders an empty list or a "no results" state where content is expected, visible in the screenshots.
  • Failed requests with 401 or 403 status to your backend from public pages, and console errors from data fetching.
  • The scan visits as a logged-out visitor and cannot read your RLS policies, so it finds the public symptom, not the policy that causes it.

See exactly what a full report contains in the sample report.

Frequently asked questions

Why does Supabase return an empty array instead of an error?

That is how Row Level Security is designed. A policy works like a filter added to every query, so rows the user is not allowed to see are simply left out. From the app's point of view the query succeeded and found nothing.

Is it safe to just turn RLS off?

No. Your Supabase anon key is in the browser by design, so with RLS off anyone can query the table directly. Turning it off briefly in a development copy is a fine way to confirm the cause, but production tables need policies.

It works for me but not for other users. Why?

Often the rows were created while you were logged in, so they carry your user id, or you are testing in the editor preview where your own session is present. Test the live site in a private window with a brand-new account to see what real users see.

Done for you · not automated

Rather have a QA engineer test it by hand?

If this is a site you're launching or handing to a client, I'll go through it by hand, including the Lovable-specific issues a scan can't reach, like logged-in flows.

$299one-time · 3 business days
  • Up to 10 key pages tested by hand, not a scan
  • Every flow a customer uses: forms, sign-up, checkout, booking
  • Real mobile and desktop browsers
  • A written report in plain language, with screenshots
  • A 15-minute call to walk you through it
  • 10 years of professional QA experience

Tell me about your site and I'll reply personally, usually the same day.

No payment now. I'll confirm scope and price first.

Related fixes

More for Lovable: all Lovable fixes · Lovable testing · 9 bugs every AI-built site ships with

Written by Waqas Ahmad, QA engineer with 10 years of professional testing experience. Last checked October 26, 2026.

Sources: Supabase: why is my select returning an empty data array · Witscode: Supabase RLS in Lovable · Escape: vulnerabilities in vibe-coded apps