FixLoop

Lovable preview uses the same database as your live app

Guide · October 15, 2026

The preview looks like a sandbox. It is not. Lovable calls it a staging environment for code: it always runs your latest work, and visitors see the last published snapshot. The backend is shared. A change to the database hits the published app too.

Drafts do the same split. App edits stay in the draft until you accept them. The database, files, and settings do not. Rows you add, edit, or delete while testing are real. Deleting the draft does not put them back.

Sources: Preview, Drafts, Database, Test and Live (retired), and Publish.

What the preview isolates

It isolates the running app you are building. It does not isolate the data that app reads and writes.

• Code, yes. The preview always shows your latest work. Visitors still see the published snapshot until you publish. That is the staging part.
• Data, no. Lovable's preview docs say it in one sentence: the preview and your published app share the same backend and data, so changes to your database affect both.
• Each draft has its own preview URL, so you can compare an idea against the main version. That URL is still talking to the same backend.
• A share-preview link shows the latest in-progress version. Same data rule.

If you sign up, place an order, edit a customer, or delete rows in the preview, you did that in live data. The published site will show it even though you never published the new UI.

This is a different problem from preview works, deploy breaks. That guide is env: production talking to the wrong API. This one is the opposite assumption: that preview is a safe copy of production.

What a draft isolates

A draft is a separate copy of the app. Own chat, own preview, own edits. Accepting merges those edits into the project. Accepting is not publishing. Visitors see the new UI only after you publish from the main version.

A draft has no backend of its own. On Cloud it uses the same database, the same files, and the same settings.

• Data you add, edit, or delete while testing is real. Deleting the draft does not undo it.
• If you edit or delete a record the app already has, the published app sees that too. Lovable's advice: create your own records to test with.
• New tables and columns are prepared in the draft and added when you accept. Pages that read a table that does not exist yet will error in the draft preview until then. That error is expected.
• Lovable will not remove or rename tables or columns from a draft, and it will not change a column's type. It adds a new column instead, or it points you at the SQL editor.

Edits in the Database view apply directly to the same database the published app uses. Delete rows cannot be undone. The SQL editor asks you to confirm DELETE, DROP, TRUNCATE, ALTER, and UPDATE. Treat that confirm as "this is live."

Schema changes are recorded as migration files (Drizzle) under drizzle/migrations/. Older projects may still have them under supabase/migrations/.

Did you have Test and Live?

For a while, Cloud had a beta with a Test database and a Live database. You built against Test. Publishing copied code and schema (plus storage bucket definitions, RLS policies, and edge functions) to Live. It did not copy rows, files, or auth settings.

That beta is over. On October 5, 2026 Lovable retired Test and Live. Every Cloud project now runs on a single database. The data you work with while building is the data the published app uses. Drafts replaced the workflow, without a second database.

How to tell:

• After October 5, the Test / Live switcher no longer appears in the Cloud view. If you do not see it under More → Cloud, you do not have a second database now.
• New Cloud projects already used one database. If you never saw Test and Live, you never had the split.
• Lovable's changelog says the beta closed to new Cloud projects on March 24, 2026. Existing projects kept it until the October 5 retirement. (Changelog)
• If you did use it: Test databases were detached on October 5 and stay restorable until November 4, 2026, then they are deleted. Publishing never moved that data for you.

How to test without hurting real data

Preview and drafts will not give you a second Cloud database. Practical options:

1. Dedicated test accounts. Sign up as a user that is obviously not a customer. Keep that login for preview and drafts.
2. Clearly marked test rows. A TEST- prefix, a flag column, or a separate test org. Do not reuse real customer rows. Lovable says to create your own records to test with.
3. Never bulk delete or run destructive SQL while "just testing." The SQL editor will ask you to confirm. That confirm is the live database.
4. Prefer additive schema changes. Lovable already refuses drop, rename, and type-change by default, and adds a column instead. Do not turn on backward-incompatible migrations unless you mean it.
5. Export important tables before a risky change. The Database view can export CSV. Cloud also keeps daily backups for about 14 days. A restore rolls back schema and data, and anything after that snapshot is gone.
6. For real isolation, use a second project. Each Lovable Cloud project has its own backend. You can also connect your own Supabase project instead of Cloud. If you want staging, that means a separate Supabase project: two Lovable projects pointed at the same Supabase overwrite each other's secrets, including LOVABLE_API_KEY. Lovable does not document a first-class staging database now that Test and Live is gone, so treat a second project as your own setup, not a product feature.

If it already happened

Stop writing. Close the SQL editor. Do not delete the draft hoping the rows come back.

1. Open the published URL in a private window, and open the Database view. Confirm what is actually gone or changed. Preview cookies will lie to you about which UI you are on. They will not lie about the data. It is the same store.
2. Export what is left (Export CSV) so a second cleanup does not make recovery worse.
3. On Cloud: More → Cloud → Database → Backups. Daily snapshots, about 14 days. Restore is permanent. Schema goes back too, so the app may not match. Only restore if you understand that trade.
4. If you had Test and Live and the missing data lived in Test, that database may still be restorable until November 4, 2026. After that it is gone. Lovable's docs point at support for help with that migration.
5. If publish failed because a database change conflicts with existing data: stop retrying. The publish banner says to ask the assistant, and Lovable confirms before changing real data.

We cannot promise a restore. If the rows are gone and the backup window missed them, they are gone.

Questions

Preview fine, production talking to the wrong API: works in preview, breaks after deploy. Login only broken on the live domain: preview vs production login.