Denly

Run Supabase migrations safely in a Lovable project

Updated 2026-11-03

Lovable writes the SQL for a Supabase schema change, shows it in the project chat, and runs it only after you approve. The safe habit is to read that SQL, keep the migration file it saves, and stop changing the live database by hand beside that history.

This is for a Lovable project connected to a Supabase project in your own account. Lovable’s built-in backend is a different product. It is on by default, and Lovable’s Supabase guide says switching between the two is not automatic. Connecting Supabase does not move tables, users, or files for you. If the app still uses the built-in backend, export what you need first. Lovable’s external hosting guide describes CSV export per table and a full database export under More, Database, Manage, Settings.

Connect a Supabase project you own

A workspace owner or admin links the Supabase organization once: Connectors, Supabase, or Settings, General, External Supabase, then Add Organization. Anyone who can edit the Lovable project can then connect it to a project in that organization. In an existing project with no backend yet, open Settings, General, External Supabase, click Connect, and pick the project.

Lovable shows a warning when another Lovable project already uses that Supabase project. The two projects overwrite each other’s secrets, including LOVABLE_API_KEY, and features that depend on that key stop working. Use a separate Supabase project unless you meant to share one.

Lovable can create a project when no backend is connected. Check its region before approval; it cannot be changed later. Manage failed creations in Supabase’s dashboard.

Read the SQL before you approve it

Lovable shows migration SQL in chat and asks before applying it. Row changes and storage bucket changes also require approval.

Read the SQL as a reviewer, not as a formality. Approve a change that adds a table, a nullable column, an index, or a policy you understand. Stop when you see any of these unless you asked for them:

In the SQLWhat to do
drop table, drop column, truncateStop. Take a backup or a dump first, and confirm the app no longer reads that data.
delete from without a whereStop. That statement removes every row.
disable row level security, or no enable row level security on a new table in the exposed APIStop. A table in the public API without row level security is readable according to your grants, which is often wider than you think.
A policy with using (true) or with check (true) for anon or authenticated on insert, update, or deleteStop unless every signed-in user, or every visitor, is supposed to write every row.
grant to anon beyond what the screen needsStop and ask Lovable to narrow it to the role and the statements you need.

Before you approve a drop or a rewrite of existing rows, take a backup. The Supabase dashboard’s backup page shows what this project can restore. Do not assume a backup exists. A plain supabase db dump exports schema only, not rows or custom roles. Export rows separately with supabase db dump --linked --data-only --file data.sql, save the schema too, and verify the restore procedure before relying on those files. Managed schemas and stored files need separate coverage. See the db dump reference.

A migration that is usually safe to approve
create table public.feedback (
  id bigint generated always as identity primary key,
  user_id uuid not null references auth.users(id),
  message text not null,
  rating integer not null check (rating between 1 and 5),
  created_at timestamptz not null default now()
);

alter table public.feedback enable row level security;

create policy "owners read their rows"
  on public.feedback
  for select
  to authenticated
  using (auth.uid() = user_id);

This example defines the ownership column its read policy uses. It permits an authenticated user to read only their own rows, subject to table grants; it does not grant client inserts, updates, or deletes. Add those policies only when the feature requires them. See Supabase’s row level security guide.

Keep the migration file, and do not replay it by hand

After you approve, Lovable runs the migration on your Supabase project, writes the file under supabase/migrations/, and regenerates the TypeScript types the app imports. That file is the history. If GitHub sync is on, the file should show up in the repository as well. The steps for connecting GitHub are in how to update a Lovable project.

Do not paste the same SQL into the Supabase SQL editor afterwards. Supabase’s migration guide is blunt about this: once you are using migrations, schema changes on the remote database belong in migration files. Dashboard DDL bypasses supabase_migrations.schema_migrations. That can leave schema drift even when migration timestamps agree; a later migration may fail or a fresh database may differ from production. The Table Editor is fine for inspecting rows. The SQL editor is fine for a select. Schema changes go through the approval card.

For data repairs, preview an update or delete with a select using the same where clause first.

Preview with the CLI when you also work outside Lovable

Install the Supabase CLI when you want a local database or you edit migrations in git yourself. Updating that CLI is a separate checklist. Link the project you connected in Lovable, not a different one.

Preview, then apply, against the linked project
supabase login
supabase link
supabase db push --dry-run --linked
supabase db push --linked

db push applies only migrations that are not already in the remote history table. The first successful run creates supabase_migrations.schema_migrations. --dry-run prints what would run and applies nothing. Review the project and migration list before applying. Do not rely on a prompt to protect production: defaults differ between commands, and automation can accept prompts.

Do not pass --include-seed against production. Supabase documents seed data for development and testing. Do not run supabase db reset against the remote project. Without a remote target, reset rebuilds the local database. With --linked or --db-url, it drops user-created objects on that remote database.

If the histories have already drifted because someone changed the live schema in the dashboard, stop pushing. Supabase’s CLI uses supabase migration repair to mark a version applied or reverted without running it, and supabase db pull --linked to capture a remote schema as a new migration. Read the repair output before you accept it. Repairing the wrong version makes the next push skip a migration that never ran, or run one that already did.

Check auth, row level security, and secrets after the change

Authentication settings stay in the Supabase dashboard, not in Lovable. Social providers such as Google need the provider enabled there, with the OAuth credentials that provider issued, before a button in the app can succeed. Lovable’s guide says you can turn off email confirmation while you test, and turn it back on before real users arrive. Do that last step. A launched app that still confirms nobody will create accounts you did not expect to be instant.

For a private table, test through the app or Data API with the public client key while signed out, then as two different users. Verify that neither can read or write the other’s rows. The dashboard’s privileged Table Editor does not simulate these roles. Never use a service-role key for this check. Ask Lovable for a follow-up migration rather than flipping a switch in the dashboard that never lands in supabase/migrations.

Secrets such as a Stripe key are entered through Lovable’s secure input and stored in the Supabase project. Lovable’s guide says those values are not written into the app repository and are not read back by Lovable. After the migration, search the git diff for the key anyway. A prompt that said “put the key in the function source” is how a secret lands in a public repository. If you find one, revoke it at the provider and set a new value in Supabase’s function secrets.

A migration that changes columns does not update an edge function that still expects the old ones. If the form fails after you approve, read the function logs under Edge Functions before you approve a wider follow-up.

For weekly upkeep, you can manually create a recurring dependency-review task with Denly’s task schedules after connecting a project and runner. Configure its instructions and review gates before enabling it. The public report form below creates a report; it does not create a schedule or a pull request. The dependency report does not read your database. For the schema, the approval card is the check. For the Next.js or npm packages around it, use the Next.js 16 checklist and the report form on this page.

Commands and product behavior on this page were checked against the vendor documentation linked here on 3 November 2026. Those products change their screens. If a label has moved, follow the linked page rather than a memory of this one.

Free, no account

Check this repository

Paste a public GitHub URL. Denly checks supported npm, pnpm, and Yarn dependency files and writes a shareable report of outdated direct dependencies and known advisories.

Public repositories only. The report checks dependency metadata, not application code or your database. It shows scan limits and does not change files or open a pull request.

Read next

How to update a Lovable project: GitHub sync and a one-time export · Upgrade Next.js 15 to 16: a practical checklist