Lovable Supabase issues: empty data, paused databases and schema drift fixed

Symptom

A Lovable app with a Supabase backend tends to fail quietly. Lists come back empty with no error. A save looks like it worked and nothing is stored. Data that loaded yesterday doesn't load today. An Edge Function that sends email or calls an AI model stops responding.

When the connection itself is the problem, Lovable shows one of these messages, both listed in its Supabase troubleshooting:

The first usually means the linked Supabase project was deleted or your access changed. The second means it is paused or still being set up.

Why it happens

There are two backends, and they are fixed in different places. Lovable's built-in backend runs on Supabase's foundation, managed for you under the More menu: Database, Users, Storage, Edge functions, Secrets and Logs. Your own Supabase project is connected from Settings, then General, then External Supabase, and checked under More, then Supabase. Several features only exist on the built-in backend: the in-editor Database, Users, Storage and Secrets views, managed backups, pausing and instance resizing, auth emails from your own domain, auth set up through chat (including managed Google sign-in) and signed-in browser testing. If you are on your own Supabase project, those fixes happen in the Supabase dashboard.

Row level security returns nothing rather than failing. Once security is enabled on a table, Supabase returns no rows through the public key until a policy allows them. Lovable adds policies when it builds features, but a table added later, or a policy that checks the wrong column, gives you an empty list and no error.

Databases pause. Lovable pauses a built-in backend after about 7 days without activity, unless the project has scheduled jobs. While paused, the published app can't read or write data, sign anyone in, serve files or run Edge Functions, and visits don't wake it. Supabase's own Free plan pauses projects after a week of low activity too.

Schema changes made outside Lovable's migrations. When you approve a change in chat, Lovable saves it as a migration file and regenerates the TypeScript types. Current built-in backend projects keep these under drizzle/migrations/; older setups and projects on your own Supabase use supabase/migrations/. SQL you run in Lovable's SQL editor is not saved as a migration. Neither is anything you change directly in the Supabase dashboard. The live database and the code's picture of it drift apart, and the next migration or an export to another host misses those changes.

Shared Supabase projects. If two Lovable projects use the same Supabase project, they overwrite each other's secrets, including LOVABLE_API_KEY. Lovable now warns you about this, but older setups may predate the warning.

The fix

1. Confirm which backend you are on

Open More. If you see Supabase with a project name and dashboard links, you're on your own project. If you see Database, Users and Storage views, you're on the built-in backend. Everything below says where each fix lives.

2. Read the logs before prompting

On the built-in backend, open More, then Settings, then Logs and pick the log type: PostgreSQL logs for query errors, Function logs and Edge logs for Edge Functions, Authentication logs for sign-in. Logs don't update live, so click Refresh. On your own Supabase, Edge Function logs are in the Supabase dashboard.

In code, supabase-js returns errors instead of throwing them. A lot of generated code ignores the error and renders an empty list, which hides the real cause:

const { data, error } = await supabase
  .from("projects")
  .select("id, name, updated_at")
  .eq("owner_id", user.id);
 
if (error) {
  // A blocked write or a bad column shows up here. A blocked read does not:
  // RLS just returns no rows, so an empty array can still mean "not allowed".
  console.error("projects query failed", error);
  throw error;
}

3. Find tables with no security or no policies

Run this in More, then Database, then Manage, then SQL editor, or in Supabase's SQL editor:

select
  c.relname as table_name,
  c.relrowsecurity as rls_enabled,
  (select count(*) from pg_policies p
    where p.schemaname = 'public' and p.tablename = c.relname) as policy_count
from pg_class c
join pg_namespace n on n.oid = c.relnamespace
where n.nspname = 'public' and c.relkind = 'r'
order by policy_count, table_name;

Security off means anyone with your public key can read the table. Security on with zero policies means nobody can. Both need fixing. A standard owner policy:

alter table public.projects enable row level security;
 
create policy "Owners can read their projects"
on public.projects for select to authenticated
using ( (select auth.uid()) = owner_id );
 
create policy "Owners can add projects"
on public.projects for insert to authenticated
with check ( (select auth.uid()) = owner_id );

Remember this SQL editor run won't be saved as a migration. Step 5 deals with that.

4. Wake a paused database

On the built-in backend, open the project in the editor, or click Wake up on the paused card in More, then Database. It takes a few minutes. If it paused because you ran out of credits or hit a limit, top up or raise the limit first. On your own Supabase project, open it in the Supabase dashboard and resume it. Supabase's docs say projects on a paid plan are not paused for inactivity, and a paused Free project can be restored for up to a year.

5. Get schema changes back into migrations

Look in the migrations folder (drizzle/migrations/ or supabase/migrations/) in your GitHub repository and compare it with what is in the database. For anything you changed by hand, paste the SQL into Lovable's chat and ask it to record the change as a migration written so it is safe to run again (if not exists, create or replace). Approving it saves the file and regenerates the types. From then on, make schema changes through chat only.

6. Give each Lovable project its own Supabase project

If two projects share one, create a new Supabase project for one of them, connect it, and set its secrets again. Rotate any key that both projects could see. Secrets go in through Lovable's secure input and are stored in Supabase. Lovable can't read them back, so keep your own record of what each one is for.

How to prevent it

• Run Lovable's Quick scan on publish and read what it says about tables without per-record access control. Run the Deep scan before launch.
• Treat the SQL editor as read-only for schema. Make structural changes in chat so they land in migrations.
• Connect GitHub so you can see every migration Lovable writes.
• Keep a pre-launch test that signs in as two users and checks each can only see their own data.
• If the app will sit idle between demos, expect the pause. For a real launch on your own Supabase project, a paid Supabase plan avoids inactivity pauses.

When to get help

Database problems are cheap to fix early and expensive once real data is in the wrong shape. This page sits under my guide to fixing a vibe-coded app, and fixing the database schema in an AI-built app covers structural problems in more depth. If your users can't sign in or see empty pages after login, read the Lovable auth guide next. If the data loads but slowly, see why your Lovable app is slow.

For the full Lovable launch checklist, read taking a Lovable app to production. Run the free vibe-code health check for a first read, and if the database needs proper work, a Rescue Sprint audits and fixes it at a fixed price agreed after the check.