Your app saves data to Supabase, but it never shows up

You built an app with Lovable, Bolt, or v0 on top of Supabase. Submitting a form works, no errors anywhere, and you can even see the row in the Supabase dashboard. But the app itself shows nothing. Or worse: it works perfectly for you and shows an empty screen for every other user. Your data is fine. Your Row Level Security policies are not.

Why this happens to AI built apps specifically

Supabase tables can have Row Level Security (RLS) turned on. When it is on, every read and write is checked against per-table policies, and a table with RLS enabled and no matching policy silently returns zero rows. Not an error, just nothing. AI app builders create your tables and often enable RLS (or Supabase prompts you to), but they routinely forget to write the policies, write a policy for insert but not select, or write a select policy that checks auth.uid() = user_id on rows where user_id was never filled in. The insert succeeds, the select filters everything out, and no error appears anywhere.

Confirm it in two minutes

1. Open your deployed app, press F12 for devtools, and watch the Network tab while the empty page loads. Find the request to rest/v1/your_table. If it returns status 200 with an empty array [], this is RLS. (A 401 or 403 also points at policies, or a missing anon key.)
2. In the Supabase dashboard, open Table Editor and confirm the rows exist. If the dashboard shows data the app cannot see, that is the signature: the dashboard bypasses RLS, your app does not.
3. Go to Authentication, then Policies (or Table Editor, select the table, then the RLS badge). Look at what policies exist for the table, per operation.

The fix

Write explicit policies for each operation the app performs on each table. In the Supabase SQL editor, for a table where every signed in user may read everything:

create policy "Authenticated users can read"
on public.your_table for select
to authenticated
using (true);

For a table where users should only see their own rows:

create policy "Users read own rows"
on public.your_table for select
to authenticated
using (auth.uid() = user_id);

Two traps to check while you are in there:

• The null user_id trap. If your select policy checks auth.uid() = user_id, verify the insert actually sets user_id. AI builders often omit it, so every row has null and matches nobody. Either set it in the insert code, or give the column a default of auth.uid().
• Public pages need an anon policy. A policy granted to authenticated returns nothing for logged out visitors. If a page should be public, the policy needs to anon, authenticated.

Then test with two different accounts, not just your own. "Works for me, empty for everyone else" is exactly what a half written policy looks like, and one test user cannot catch it.

Do not do this

Disabling RLS makes the symptom disappear and publishes your entire table to anyone with your project URL and anon key, both of which ship inside your frontend bundle. The AI tool may even suggest it when you paste the symptom back into the chat. It is not a fix, it is an incident waiting for traffic.

Still stuck?