An AI builder can create a table in seconds. The production problem begins when nobody can answer a more important question later: which database changes are actually live, in what order, and can we reproduce them safely?
If your Supabase-backed app has real users, payments, permissions or important business data, stop treating schema changes as disposable prompts. Put them into a migration workflow.
That does not mean AI-assisted development is unsafe. It means the database needs a source of truth stronger than the last successful prompt.
The short answer
For a production Supabase app, I want database changes to move through this chain:
change requested → migration created → migration reviewed → tested away from production → committed to Git → production deployment → verification
The exact tooling can vary. The important part is that a table, policy, trigger or constraint should not exist only because someone clicked around a dashboard or an AI agent executed SQL against the live project.
Supabase’s current database migration documentation makes the same source-of-truth problem explicit: once you use migrations, direct schema changes on the remote database bypass migration history and can cause later db push sync errors.
Why AI-built apps reach this problem quickly
AI tools are very good at accelerating implementation. You can describe a feature and receive SQL for tables, indexes, policies, triggers and functions almost immediately.
That speed changes the failure mode.
The risk is no longer only “can we build this?” It becomes “did the generated change actually run everywhere it was supposed to run?”
You can end up with:
- a migration file in Git that was never applied;
- a production table created manually but absent from the repository;
- an RLS policy changed in the dashboard but missing from migrations;
- development and production databases with different constraints;
- two agents producing migrations from different assumptions;
- application code deployed before the schema it depends on;
- a developer unable to recreate the database from the repository.
A working UI can hide those differences for a surprisingly long time.
Git should explain how the database got here
A migration is a versioned database change. Supabase stores migration files under supabase/migrations, while the remote project tracks applied migrations in its own migration-history table.
That gives you two useful records:
- Git records the intended database changes.
- Supabase records which migrations have actually been applied.
Supabase’s CLI documentation explains that db push compares local migrations with the remote migration history and applies only migrations that have not yet run.
That is much safer than asking an AI agent to “fix the production database” without first establishing its current state.
A practical workflow for AI-assisted Supabase changes
1. Ask the agent for the change, not unrestricted production access
Let Lovable, Codex or another coding agent help reason about the schema and generate the migration.
But make the artifact reviewable. You should be able to inspect the SQL that will create, alter or remove database objects before it reaches production.
For an existing Supabase project, first establish whether the repository already contains a trustworthy migration history. If it does not, do not pretend it does.
2. Test the migration away from production
A migration that parses correctly is not automatically safe.
Test what happens to existing rows, constraints, RLS policies, triggers and application queries. For destructive changes, think about what happens while old application code and new application code overlap during deployment.
Supabase’s current environment-management guide recommends separate development and production environments, with staging where appropriate. It specifically recommends CI/CD for deploying new migrations to production rather than casually deploying from a local machine.
3. Commit the migration with the application change
If a feature requires a new column, policy or function, the code and the database change belong to the same release story.
The repository should make that dependency visible to the next person, including future you and future AI agents.
This is especially important when multiple tools touch the same product. Lovable may generate the initial app, Codex may refactor it, GitHub may become the code source of truth and Supabase may hold production state. Versioned migrations are one of the boundaries that keeps those tools from silently disagreeing.
4. Preview what production will receive
Before applying migrations, verify the target project and inspect what is pending.
Supabase documents supabase db push --dry-run as a way to preview migrations that would be applied. That small check matters when you manage more than one Supabase project.
The dangerous command is often not a sophisticated one. It is a correct command pointed at the wrong environment.
5. Deploy through one controlled path
Do not have a developer, an AI agent and a CI workflow all racing to mutate the same production schema.
Choose one production deployment path.
Supabase supports GitHub-based deployments and CLI-driven CI/CD. Its deployment documentation recommends developing locally, pushing changes to Git and deploying from the production branch; teams that need more isolation can use staging or preview environments.
The goal is not ceremony. It is to know who or what is allowed to change production.
6. Verify after deployment
A green deployment is evidence, not the entire acceptance test.
Verify the feature against the production environment. Check that expected migrations are recorded, the relevant tables or functions exist, authorization still behaves correctly and the application can perform the real user journey.
For sensitive apps, I also want a rollback or forward-fix plan before a destructive migration runs.
What to do when production has already drifted
Do not generate another migration immediately.
First compare three things:
- the migration files in Git;
- Supabase’s remote migration history;
- the actual production schema.
Supabase documents supabase migration list for comparing local and remote migration status. Its migration guide also covers migration repair for history mismatches, but repair should follow diagnosis, not replace it.
If someone manually added a production column that the repository does not know about, marking a migration as applied without understanding that difference can preserve the confusion instead of resolving it.
The first question is always: where did intended state and actual state first diverge?
That is the same debugging principle I use for deployments, payments and forms. Find the broken boundary before changing more layers.
Do you need Supabase Branching?
Not necessarily.
A disciplined migration workflow can work with local development and CI/CD. Supabase also offers Branching, which creates isolated environments for testing schema and other changes before production.
In May 2026, Supabase also made dashboard-based Branching 2.0 available by default, giving teams another way to create an isolated branch, review a schema diff and merge changes without requiring a Git connection.
Use branching when the isolation is valuable. Do not mistake buying or enabling more tooling for having a release process.
The production-readiness test I would use
Before I call an AI-built Supabase app production-ready, I want clear answers to these questions:
- Can we recreate the important schema from versioned migrations?
- Can we tell which migrations production has applied?
- Are RLS policies and database functions captured with the schema history?
- Can a schema change be tested without experimenting on live user data?
- Is there one controlled path for production database changes?
- Does the deployment verify the real application journey afterward?
- If a migration fails halfway through the release, do we know what happens next?
If the answer to several of those is “we usually ask the AI to fix it,” the app is still operating like a prototype even if the interface looks finished.
For the broader release review, use my AI-built app production checklist. If the issue is specifically permissions rather than schema deployment, see Lovable + Supabase RLS: What to Check Before You Launch. And if your AI-built product has reached the point where the prototype works but production state is becoming difficult to trust, my MVP development service is built around that transition.
