An AI-built app can look recoverable because the code is in GitHub and Supabase says backups exist. Those are two different safety nets.
Your repository can help you rebuild application code and database schema. A database backup can help you recover database state. Neither automatically means you can recreate the whole working product after a destructive migration, accidental deletion or failed production change.
For an app built with Lovable, Codex, Cursor or another AI-assisted workflow on Supabase, the practical question is not “Do I have backups?”
It is “If production breaks tonight, what exactly can I restore, what is missing, and have I tested the path?”
The short answer
Supabase backups are valuable, but treat them as one part of recovery rather than a magic undo button for the entire application.
Supabase’s current backup documentation makes one limitation especially important: database backups do not contain the actual objects stored through the Storage API. The database contains metadata about those objects, but restoring the database does not bring deleted file objects back with it.
Supabase also documents components that may need separate recreation when moving or restoring a project, including project configuration outside the database.
Before real users depend on the app, know the recovery boundary.
Separate four things that builders often call “the app”
When an AI builder gives you a working product, it is easy to think of the deployment as one unit. Operationally, it is several.
1. Application code
This is your frontend, server code, configuration committed to the repository, migrations and functions that are actually version-controlled.
GitHub can be an excellent recovery source for this layer, provided the latest production state is committed and the repository is under an account you control.
2. Database state
This includes tables, rows, relationships and other database objects captured by the relevant backup method.
This is where Supabase database backups do important work. If a bad operation deletes customer records or corrupts data, a recovery point can be far more useful than trying to reconstruct production state from code.
3. User-generated files
Receipts, avatars, documents, product images and uploads may live in Supabase Storage.
This is where the phrase “database backup” can create false confidence. Supabase explicitly says its database backups do not include the objects stored through the Storage API. Restoring old database metadata does not restore an object that was deleted from Storage after that backup.
If files matter to the business, they need their own recovery thinking.
4. Hosted project configuration
A working application can also depend on Auth settings, API keys, Realtime configuration, Edge Functions, extensions, scheduled jobs, webhooks and external integrations.
Supabase’s restore guidance lists several items that are not stored directly in the database and may need to be recreated, including Edge Functions, Auth settings and API keys, Realtime settings and read replicas.
That means successful database recovery and successful product recovery are not always the same event.
Why this matters more in AI-assisted development
AI-assisted building shortens the distance between idea and production.
That is useful, but it also makes destructive actions easier to request without fully appreciating their operational boundary. A prompt such as “clean up these tables”, “reset the database”, “replace the old schema” or “remove unused storage” can represent a much larger change than its wording suggests.
The solution is not to stop using AI. It is to put irreversible operations behind stronger human checks.
Before a production data change, ask:
- Which environment am I connected to?
- Is this production or a disposable development project?
- Is the change reversible through a migration?
- What data could be deleted or transformed?
- Is there a recent recovery point?
- Does that recovery point include the assets I care about?
- Have I tested the restore path somewhere safe?
That final question changes backup from a checkbox into an operational capability.
A backup you have never restored is still an assumption
Seeing a successful backup timestamp is reassuring. It does not prove your recovery procedure works the way you think it does.
Supabase supports restoring a backup into a new project in supported scenarios. Its restore-to-new-project documentation specifically recommends reviewing and testing the restored project before relying on it. It also warns that some database extensions can begin external operations as soon as a binary restore completes.
That is a useful reminder: recovery itself can have side effects.
A sensible rehearsal is not “click restore and hope”. It is closer to:
- identify the recovery point;
- restore into a safe target where the method allows it;
- verify critical tables and representative records;
- verify authentication expectations;
- verify Storage separately;
- check functions, scheduled work, webhooks and external integrations;
- run the application’s most important user journeys;
- document what still required manual recreation.
For a payment product, that might include creating a test transaction and checking the state transitions around it. For a property app, it could mean verifying that the right user can still see the right tenancy records and documents. For a booking product, test availability, confirmation and cancellation flows.
The restore is not complete merely because Postgres starts.
Do not confuse code rollback with data rollback
AI builders often make version history feel like a universal undo button.
It is not.
Rolling your repository back can restore yesterday’s application code. It cannot automatically resurrect a row that was deleted from today’s production database. Restoring yesterday’s database can recover data while leaving today’s application code expecting a newer schema.
That mismatch is one reason migrations matter.
My guide to Supabase database migrations for AI-built apps explains how versioned schema changes reduce production drift. The broader AI-built app production checklist covers the other launch boundaries that a working demo can hide.
Think of these as separate controls:
version control answers: what code and schema changes did we intend?
backup answers: what recoverable state do we have?
restore testing answers: can we actually return the product to a usable condition?
You want all three.
Storage deserves its own recovery plan
This is the easiest gap to miss.
Suppose an app lets users upload invoices. The database may contain a row describing each file, its bucket and its path. The actual invoice file is an object in Storage.
If an operation deletes those objects, restoring database metadata alone can leave records pointing to files that no longer exist.
Supabase’s documentation is explicit about this boundary, so do not design business continuity around an assumption that database backup equals file backup.
For important user-generated assets, decide how much loss is acceptable and create a separate process that matches that risk. The right implementation depends on the product, data sensitivity, storage volume and recovery requirements.
Know the downtime and side effects before an emergency
Recovery is easier to reason about before the incident.
Supabase notes that an in-place restoration makes the project inaccessible during the restore process. With point-in-time recovery, the selected backup and transaction logs are replayed to reach the requested recovery point.
That has practical business implications. If the app takes bookings, payments or submissions, decide what users should see while recovery is happening. If webhooks or scheduled database jobs can fire after a restore, understand those effects before using a restored project as production.
The technical recovery plan should include the user experience of failure too.
A simple production recovery checklist
Before an AI-built Supabase app handles irreplaceable data, I would want clear answers to these questions:
- Where is the application source of truth?
- Are schema changes represented as migrations?
- What Supabase backup method and retention are available on the current plan?
- What database state can be recovered?
- Which Storage objects need separate protection?
- Which Auth, Realtime, Edge Function or project settings must be recreated?
- Which secrets and third-party credentials are stored outside the database?
- Can a recovery be tested without overwriting production?
- What critical user journeys prove that recovery worked?
- Who can perform the recovery if the original builder is unavailable?
If several answers are “I don’t know”, the app may be deployable without yet being recoverable.
Recovery is part of ownership
Owning the GitHub repository and Supabase project is important. Real product ownership goes further: you should be able to explain how the system is changed, how it is observed and how it is recovered.
That is especially important when AI helped build the first 80% quickly. Production confidence comes from making the remaining boundaries explicit.
If you have an AI-built MVP that works but you are unsure whether its database, Storage, permissions, deployment and recovery setup are safe for real users, I can review those production boundaries through my MVP development service. If there is already a specific recovery or architecture problem, contact me with the stack and what you are trying to protect.
