Lovable Cloud Now Records Database Changes as Migrations and Blocks Breaking Ones
From 7 October 2026, changes to Lovable Cloud databases are recorded as Drizzle migration files under drizzle/migrations/, and changes that could break a published app are refused unless the "Execute backward incompatible database migrations" permission is enabled. Why this is a big deal for AI-built apps, plus new resource-health warnings.
One of the riskiest moments in an AI-built app is when the AI changes the database of an app that real people are using. On 7 October 2026, Lovable shipped two safeguards for Lovable Cloud databases.
1. Every database change becomes a migration file
Cloud database changes are now recorded as Drizzle migration files under drizzle/migrations/ in your project.
Why that matters:
- History. You can see exactly what changed in your schema, when, and in what order — in git, alongside the code. (What Are Database Migrations?)
- Reproducibility. A fresh environment (a copy for testing, or a new host) can be brought to the same schema by running the migrations.
- Portability. If you export your project to GitHub and move hosting, the schema comes with it as standard SQL migrations. (Export a Lovable Project to GitHub, Drizzle vs Prisma)
2. Breaking changes are refused by default
Changes that could break a published app — dropping or renaming a column the live app still reads, for example — are refused unless the "Execute backward incompatible database migrations" permission is turned on.
This is the database version of "don't deploy on Friday". In a normal engineering team, breaking schema changes go through an expand–contract process: add the new column, migrate data, switch the code, and only later remove the old column. Blocking them by default stops an AI (or you) from taking down a live app with one prompt. (Postgres Migrations on Large Tables, Zero-Downtime Deploys)
Advice: leave that permission off. Turn it on only for a specific, understood change, with a backup taken first — then turn it off again. (Backups for Beginners)
Also on 7 October
- Database resource-health warnings with a "Resolve" option.
- Resizing the database from chat on paid plans, with the credit impact shown first.
Why this matters beyond Lovable
AI agents deleting or mangling production databases has become a genre of horror story. The fixes are always the same: migrations in version control, no destructive changes without explicit approval, separate environments, and tested backups. It's good to see builders adding them as defaults. (Stop an AI Agent Deleting Your Production Database)
Source: Lovable changelog
EasySpawn runs your database next to your app with daily backups, and Claude Code works on branches with migrations you review — so schema changes reach production through a pull request, not a prompt. See how it works for AI-built apps or join the waitlist.
Related: What Is Lovable? · Database Transactions Explained · Soft Deletes and Audit Logs · Prisma Migrations in Production
Keep reading
Replit Adds Scheduled Daily Backups for Production Databases
On 4 September 2026 Replit added scheduled backups for production databases: one full restore point per day, kept for a retention period you choose (limits depend on plan), alongside a new Project Analytics pane. What it covers, what it doesn't, and the backup checklist every Replit app should still follow.
Lovable Now Uses Free and Pro Plan Data for AI Training Unless You Opt Out
Since 9 September 2026, Lovable may use customer data from Free and Pro plans to train AI models unless users opt out in Account settings → Privacy. Business and Enterprise workspaces are excluded by default. What that covers, how to opt out, and what to think about if your app handles client or customer data.