Fix Drizzle during a Lovable database move

You are moving a Lovable Cloud database to a Supabase project you control, and a Drizzle migration error has interrupted the rehearsal. Treat the archive and migration history as separate inputs: inspect the export, determine which migration layout the project actually uses, and reconcile the destination in isolation. Do not rename or regenerate migration files just to make an error disappear.

If you only need to move the app to Next.js and are keeping the same Supabase project, start with the broader Lovable-to-Next.js guide. This guide addresses the narrower case where the backend is moving too and its Drizzle history needs diagnosis.

Find the source before changing it

A Lovable app can use its built-in backend, often called Lovable Cloud, or a Supabase project connected from your own account. They can look similar from the app but offer different access. Lovable's backend guide and Supabase's identification guide explain how to tell them apart.

If you already use a Supabase project you control and will keep using it, a frontend move does not automatically require moving the database. Verify the app's URL, keys, authorization, and deployment settings instead. If you are moving from Lovable Cloud to your own Supabase project, connecting the destination does not move the backend automatically. Lovable describes a manual export, schema rebuild, and data transfer. Lovable Supabase integration

Supabase's troubleshooting page says an existing Cloud project cannot be switched directly, while Lovable's current integration FAQ describes connecting a new backend after export. Because those instructions differ, verify the current options in your specific project before disconnecting anything. A separate test project or deployment is the safer place to rehearse. Preserve access to the source until the new application passes verification. Supabase troubleshooting, Lovable integration FAQ

Inventory the move

Write down what must work at the destination:

Tables, data, schema migrations, indexes, constraints, functions, triggers, extensions, grants, and row-level security policies.
User accounts and IDs referenced by application rows, sign-in methods, redirect URLs, email templates, and OAuth configuration. Confirm which identity data the actual export contains and whether your chosen destination can use it; validate password and session behavior in the rehearsal.
Storage buckets, object contents, and access rules. Database records alone do not prove that files moved. Supabase backup limitations
Edge Functions, environment variables, secrets, scheduled jobs, webhooks, Realtime, and payment or email integrations. Configure test endpoints so a rehearsal cannot charge customers or send real messages.
Current project code and a recovery copy of the source. Record a cutover window and the maximum acceptable data loss.

For the built-in backend, Lovable’s export guide describes More → Database → Manage → Settings → Export project data. Its compressed PostgreSQL archive includes database structure, rows, user accounts, and password hashes, but not Storage files, Edge Function code, secrets, sign-in provider settings, or project API keys. Lovable says the archive is restored with pg_restore; it documents size and frequency limits and says to contact support for larger databases. Download the export and Storage files outside the source project before removing anything. Lovable states that a restore to Supabase preserves user passwords but existing users must sign in again; test the actual path and OAuth setup yourself.

Follow the provider procedure for your actual export and destination. Do not assume a SQL migration directory is a complete backup of data, identities, files, and configuration. If the import method or identity migration is unclear, stop and resolve it with the provider before altering the source.

Inspect the export before importing

Lovable's managed Supabase migration guide describes its current export as a PostgreSQL custom-format .backup archive compressed with zstd. If the downloaded file is wrapped in a ZIP, extract that first. Use PostgreSQL client tools with zstd support; Lovable warns that a build without zstd may list an archive but fail to restore its data. The archive includes schema and rows, including managed schemas such as auth, so it is not SQL to paste into the dashboard.

On the machine holding your private export, this command lists the archive's table of contents without connecting to a database or importing data:

pg_restore --list /path/to/your-export.backup

Treat the output as confidential: table and object names can reveal details about your application. Compare the list with the intended destination, including app tables, sequences, policies, roles, and managed schemas. Listing succeeds even for some client builds that cannot decompress the data; it does not prove the archive can be restored.

Create a separate test Supabase project and follow Lovable's guide for its managed destination. The guide calls for choosing the objects and data to restore with PostgreSQL's selective-restore options, accounting for existing managed schemas and roles. Reconcile schema migrations and any seeded rows with the archive before loading them: replaying both a schema-creating migration and the same archived schema can collide, while reimporting seed rows can duplicate records. Include the sequence values needed for later inserts. Test new record creation, not just reading old rows.

There is no safe universal pg_restore command for every initialized destination and archive. The exact selection depends on what the destination already contains and which users, policies, extensions, and data must move. Do not add --clean to silence conflicts: Lovable warns that it drops restored objects. If you cannot make and review the object selection or preserve the required authentication records, stop and work through the Lovable migration guide with a PostgreSQL developer or provider support. Preserve the source and downloaded backup until the destination is verified.

Rehearse the database and access

Create a separate destination. Restore or recreate the schema and import data using the documented method for your export. Resolve conflicts with existing managed Supabase schemas deliberately. Apply reviewed changes in dependency order; do not run a generated migration against production simply because it worked on an empty database.

Use the Supabase recovery verification checks to compare critical table counts and representative records with the same source snapshot and test account-level access and actual files. Check foreign keys and user IDs, then test sign-in, functions, and callbacks. Plan how to pause writes and move any changes made since the export before switching users. Keep a rollback plan and the original source until the destination is proven.

Supabase's restore guide explains its own logical backup and restore path, including separate handling for migration history, certain auth and storage changes, and external files. It should not be assumed to describe every Lovable export format.

Identify the Drizzle layout before repairing it

Drizzle models, migration files, migration metadata, the database's applied-history table, and the live database schema are related but not interchangeable. An error can mean the tool version expects a different local layout, a file is missing, or the local history and database disagree. Copying a SQL file into another folder does not reconcile those histories.

Read the installed drizzle-kit and drizzle-orm versions from the project's lockfile and package manifest. Read , especially schema, out, and the selected config file. Do not expose its credentials when sharing it. Drizzle configuration
Preserve a copy of the migration folder and lockfile. Record which database the command targets and inspect its applied history without changing it. Compare the actual files, metadata, and database state before any repair.
In Drizzle's older 0.x layout, migration metadata uses a journal. The v1 documentation describes a newer structure with SQL and snapshots grouped in migration folders and no journal. The v1 upgrade guide documents drizzle-kit up for the format upgrade. Use it only when deliberately upgrading the matching toolchain, after reviewing breaking changes and testing a copy. Do not run an upgrade command as a generic fix for an unknown error.
Decide who owns future changes. In the current CoreMVP database workflow, SQL in owns schema changes, while Drizzle models and repositories support the application's data access. That does not make an arbitrary existing Drizzle history compatible with Supabase CLI history. Reconcile the actual schema and history with a reviewed baseline and test it in isolation; do not let two tools independently apply the same change.

Drizzle's pull can inspect an existing database and produce a schema representation, but inspection does not copy application data, migrate users, recreate external services, or prove that every platform-specific object and permission is represented. Review its output against the database and the Drizzle pull documentation. Likewise, a successful migration command alone is not an end-to-end app test.

Worked example: a 0.x journal error

Suppose a project's lockfile shows drizzle-kit 0.x and drizzle-orm 0.x. Its migration command reports Can't find meta/_journal.json file. The configuration points to ./drizzle, but a file listing shows this:

project/
  drizzle.config.ts        # out: ./drizzle
  drizzle-migrations/
    0000_initial.sql
    meta/_journal.json
    meta/0000_snapshot.json

This example shows a potential path mismatch, not proof that a journal should be regenerated. The configured output folder and the folder containing the checked-in history differ; confirm which path the failing migrator actually reads before calling it the cause. Check the actual migration invocation as well: an application migrator may have its own migration-folder argument, and relative paths depend on the process working directory. Compare the branch, lockfile, deployment artifact, and historical config with the team before deciding which folder is authoritative. Do not create an empty journal, rename files, regenerate a baseline, mark migrations as applied, or run a migration against the live database to test a theory.

For a safe rehearsal, make an isolated copy of the project and a separately provisioned test database. Restore a test snapshot or use an explicitly empty disposable database appropriate to the question. In the copy, compare the journal's entries to the SQL files and snapshots, then compare the actual database schema and its Drizzle history to the expected state. Ask the team to identify the intended folder and correct the configuration in the copy only. Generate a small reviewed test change and apply it using the project's established workflow only to the disposable target. Confirm the expected column or table and its migration record, run the command a second time to check that it does not reapply the same change, and test the application path. If the database and history disagree, stop and design a baseline or repair for that exact state; don't guess.

If the project was deliberately upgraded to the v1 toolchain, the absence of a 0.x journal can be normal: v1 uses the newer folder layout, while an old migrator may still expect the former layout. Review the installed package versions, its migrator, config, and release-specific upgrade guide together. Drizzle's v1 guide currently shows release-candidate packages and documents drizzle-kit up for a planned format upgrade. Test any upgrade on a copy and review its output before adopting it. A 0.x error alone is not a reason to upgrade. Drizzle's migration-format notes

For the broader application move, use How do I move a Lovable app to Next.js? alongside the CoreMVP database guide. Finish the rehearsal with a written list of verified behavior and unresolved gaps before choosing a cutover time.