By Partly fixable yourself. Usually one missing read policy or a stale view
What you see. The form says saved, nothing fails, but the list stays empty or the record is missing from the dashboard.
Why it happens
Three things cause this and none of them raise an error. First, Row Level Security. Supabase says that once RLS is on, no data is accessible through the API with the publishable key until you create policies. An AI builder often writes an insert policy so the save works, but forgets the select policy. A read blocked by RLS returns an empty list, not an error, so your app shows nothing.
Second, the policy cannot match the row. A rule like (select auth.uid()) = user_id never matches if the row was saved with an empty user_id, or if the user was not signed in, because auth.uid() is null for unauthenticated requests.
Third, two databases. The live site may point at a different Supabase project than the one you are looking at, since the VITE_ variables are baked in at build time. In Lovable, the Database view also does not update live, so an unrefreshed table looks empty.
Fix it yourself
- Refresh the table first. In Lovable open More > Database and click Refresh. In Supabase open the Table Editor. If the row is there, saving works and reading is blocked.
- Open Database > Policies in Supabase, or Manage > Policies in Lovable. The table needs a
SELECTpolicy, not only anINSERTone. - Look at the saved row. If
user_idis empty, ask the builder to fill it from the signed-in user on every insert so the read policy can match. - Check which project the live site uses. Compare
VITE_SUPABASE_URLin your host's environment settings with the project URL in the Supabase dashboard. - Run the Security Advisor in the Supabase dashboard. It flags tables with RLS off and policies on tables where RLS is disabled.
- Test with two accounts. Each should see its own rows and nothing else. See the checklist item DATA-03.
When to get an engineer
Get an engineer when adding one policy breaks another screen, when several tables behave this way, or when the data landed in the wrong project and has to be moved. Tell them the table name, the current policies, and which Supabase project the live site uses. A one-off check costs $49–$800 and usually finds the whole set of policy gaps at once. A single fix runs €99–$990 and takes about two days.
Top-rated companies for Supabase apps
Ranked by our score: published prices, scope of work, AI tools named, timing and a low-risk first step. How we score.
- 1Redlab10.0/10Best for: A full rescue by one team that keeps buildingFree first step · from $490
- 2Vibe Code Rescue (Lev Arakelyan)9.0/10Best for: A one-off check and a cleanupFrom $299
- 3LazyCodeLab9.0/10Best for: A one-off check and a cleanupFrom $399
Check these
Access rules are on for every table
In Supabase, open Table Editor: every table should show RLS enabled, with at least one policy. In Firebase, your rules should never say allow read, write: if true.
One user cannot open another user's records
Sign in as user A, copy a request from the Network tab, and change the record ID to one that belongs to user B. You should get an error or an empty result.
Testing and real users use separate databases
Experiments and AI agents should never run against production data.
Questions
Why is there no error message?
RLS filters rows silently on read. The query succeeds and returns the rows you are allowed to see, which can be none.
Should I switch RLS off so the data shows?
No. With RLS off, a table in an exposed schema is readable and writable by anyone holding the publishable key. Add the missing read policy instead.
Sources: Supabase docs: Row Level Security; Supabase docs: Performance and Security Advisors; Lovable docs: Database; Lovable docs: Deploying and hosting outside Lovable.