A Lovable feature can look completely finished in preview and still fail after deployment with errors such as relation does not exist, column does not exist, a missing trigger, or behavior that suggests production is running an older database model.
Do not immediately rebuild the feature.
The first question is simpler:
Does the production database actually match the database state your code expects?
With Lovable, GitHub and Supabase in the same workflow, there are several different things that can look like “the database”: the SQL migration files in your repository, Supabase’s record of migrations applied to a project, and the schema that is actually live. They can drift apart.
The short answer
When a database-backed feature works in one environment but fails in production, check these layers in order:
- Confirm the exact production error and the environment producing it.
- Confirm the application is connected to the intended Supabase project.
- Compare the migration files in the repository with the remote migration history.
- If those appear aligned, compare the expected schema with the actual live schema.
- Reconcile the difference through a reviewed migration rather than making another invisible one-off fix.
A migration file existing in GitHub does not prove that the corresponding change reached production.
Supabase documents migrations as versioned SQL changes and separately tracks which migrations have been applied to each database. Its current deployment guide explains that supabase db push compares the local supabase/migrations directory with the remote migration history and applies migrations that have not yet run: https://supabase.com/docs/guides/deployment/database-migrations
That distinction is the key to this bug.
There are three states you need to keep separate
1. The migration files in GitHub
These describe the database changes the repository expects.
A migration may create a table, add a column, create a function, install a trigger, change a policy or add an index.
If the SQL exists in the repo, you know somebody or some tool generated the change. You do not yet know whether a particular production database executed it successfully.
2. Supabase’s remote migration history
Supabase tracks applied migrations in the remote database. Its official troubleshooting workflow recommends supabase migration list when local and remote migration histories may be out of sync: https://supabase.com/docs/guides/local-development/cli-workflows
This lets you ask a much better question than “Lovable says it deployed.”
You can ask:
Which migration versions does this production database say it has actually applied?
3. The live schema itself
Even migration history is not the entire story.
Someone may have changed production directly through the Supabase Dashboard, SQL editor or another tool. The database can then contain a change that is not represented in the repository’s migration chain.
Supabase explicitly warns that remote changes made outside migrations can create schema drift. Its current guidance is to capture remote changes with supabase db pull, then verify the migration chain locally: https://supabase.com/docs/guides/local-development/cli-workflows
So the debugging model is:
repository migrations → remote migration history → actual production schema
Do not assume those three are identical. Prove it.
Start with the production error, not another AI prompt
Suppose preview works but production returns:
relation "public.invoices" does not exist
That is useful evidence.
Preserve the network response, server log or database error before asking Lovable to change anything. Then verify that production is pointing to the intended Supabase project and inspect whether the migration that creates invoices exists and was applied there.
A broad prompt such as “fix the database” can make the situation worse because the builder may generate a second migration, rename something, alter RLS or change application queries before you understand the first mismatch.
The goal is to locate the first false assumption.
Use migration history before touching production
Supabase’s documented workflow gives you a useful first comparison:
supabase migration list
If a migration appears locally but not remotely, you have evidence that the production project has not recorded that migration as applied.
That does not mean you should blindly paste the file into the production SQL editor.
Read the migration first.
Ask:
- Does it only add new objects, or does it alter existing ones?
- Does it rename or drop anything?
- Does it modify data as well as schema?
- Does it depend on an earlier migration?
- Could applying it twice cause a failure or duplicate side effect?
- Is production data backed up before a destructive change?
Database debugging becomes dangerous when “make the error disappear” replaces “understand the state transition.”
What if migration history says everything is applied?
Then investigate schema drift.
The remote database may have been changed manually after those migrations ran, or the migration chain may not reproduce the state you think it does.
Supabase provides db pull to capture remote schema changes into a migration and db diff to compare database states. Its CLI documentation explains that db diff compares a target database with a shadow database built from the local migration chain: https://supabase.com/docs/reference/cli/supabase-db-schema-declarative
That gives you a stronger test than opening the Table Editor and checking whether one table exists.
A real application depends on more than tables:
- columns and constraints
- foreign keys
- indexes
- functions and triggers
- RLS policies
- grants
- storage or auth customizations
One missing trigger can make the UI appear to save successfully while a required downstream record is never created.
Do not create a second source of truth in the SQL editor
An emergency SQL edit can be appropriate when you understand the incident and need to restore service. The problem is leaving that edit only in production.
Supabase’s current migration guide warns that direct remote schema changes bypass migration history and can cause later synchronization errors: https://supabase.com/docs/guides/deployment/database-migrations
If you repair production directly, reconcile that change back into the versioned database definition immediately.
Otherwise the next environment built from Git may recreate the old bug, and a future deployment may try to apply a change production already has.
The rule I use for product systems is simple:
If production depends on a database change, the repository should be able to explain that change.
That matters even more with AI-assisted building because schema changes can be generated faster than a human can remember which environment received which SQL.
Verify the migration chain from a clean state
A migration system earns trust when it can reproduce the database, not merely when today’s production database happens to work.
Supabase recommends supabase db reset in local development to replay migrations from scratch. Its documentation specifically suggests using a reset after pulling remote drift so you can verify that the migration chain still produces a working schema: https://supabase.com/docs/guides/local-development/cli-workflows
For a production product, I want to know that a safe test environment can be built from the versioned migrations without relying on undocumented dashboard clicks.
This catches an important class of AI-builder problem: the current database works because of accumulated manual fixes, but the repository cannot reproduce it.
Regenerate types when the schema changes
There is another layer after the database itself.
If your application uses generated Supabase TypeScript types, an updated database with stale generated types can leave the code and schema describing different worlds. Supabase’s current local-development guidance recommends regenerating types when the schema changes: https://supabase.com/docs/guides/local-development/cli-workflows
So after reconciling the schema, verify the application artifacts that depend on it too.
Do not stop at “the table now exists.”
A safe production-debugging sequence
When a Lovable + Supabase app works in preview but a database feature fails in production, I would work through this sequence:
1. Preserve the failure. Record the exact production error, request and affected user journey.
2. Verify the target project. Confirm production environment variables point to the intended Supabase project.
3. Find the expected change. Identify the migration that introduced the missing table, column, trigger, function or policy.
4. Compare migration histories. Use the supported migration tooling to determine whether local and remote histories diverge.
5. Compare schema state if necessary. If history looks correct, investigate whether the live schema has drifted from the migration chain.
6. Review before applying. Treat generated SQL as code, especially when real customer data exists.
7. Reconcile through version control. Make the repository describe the production state rather than leaving a permanent dashboard-only fix.
8. Test from a clean state. Prove that the migration chain can reproduce the intended schema.
9. Retest the actual user journey. A successful migration command is not the same as a successful product flow.
For a broader release review, use my AI-built app production checklist. If the issue is an authorization error rather than a missing object, see my guide to Lovable Supabase permission denied errors.
When to stop prompting and get engineering help
You probably do not need a developer merely because one migration is missing and its effect is clear.
Get help when the database contains real customer data and the fix involves destructive changes, when local and remote migration histories conflict, when production has undocumented manual changes, when triggers or policies differ between environments, or when you cannot confidently explain what the proposed SQL will do before it runs.
At that point the problem is no longer “make Lovable generate more code.” It is production state management.
That is exactly the kind of boundary where human product and engineering judgement matters most in an AI-assisted build.
If you need someone to diagnose an AI-built product before making risky production changes, see my MVP development and rescue service or send me the failure and context.
The objective is not to make one error disappear. It is to get Git, migration history, production schema and application expectations describing the same system again.
