When working with Prisma, database migrations are a critical part of maintaining a consistent schema. However, during development, you might prefer a quicker approach and use the prisma db push command.

Things can quickly go haywire from there.

Recently, I wanted to update my schema and was faced with the daunting suggestion to reset the database. Ugh, no thank you.
This guide will demonstrate how to avoid resetting your database by creating the missing migration files with Prisma.

The Initial Problem

I decided to add a new model to my schema:

1model User {
2  id        Int      @id @default(autoincrement())
3  ...
4  thoughts  Thought[] // Relation to thoughts
5}

After making the changes, I ran:

1npx prisma migrate dev --name add_thoughts

However, I was greeted with a warning from Prisma:

“Schema is out of sync, and the database needs to be reset.”

At this moment, Prisma suggested resetting the database, which would delete all my data. My immediate reaction was: “No! Do not reset my database!”

Here’s what happened:

• Prisma detected database drift. This means my database schema did not align with the migration history.
• I realized that using prisma db push earlier had caused this drift. This command updates the database schema directly without creating migration records.

Why Database Drift Happens

prisma db push updates the database schema directly: This is quick for prototyping but bypasses the migration system.

Using migrations after db push causes inconsistencies: Prisma compares the database schema against the migration history and identifies mismatches.

Prisma’s solution is often to reset the database: Resetting deletes all data to start fresh, which is unacceptable in most cases.

Solution: Create a Baseline Migration

Instead of resetting the database, I created a baseline migration that synchronized Prisma’s migration history with my existing database.

This process is non-destructive and preserves all data.

Here’s the step-by-step guide:

Create a Directory for the Baseline Migration

1mkdir -p prisma/migrations/0_init

This creates a folder to hold the baseline migration.

2. Generate a SQL File Representing the Current Schema

1
2
3npx prisma migrate diff --from-empty --to-schema-datamodel prisma/schema.prisma --script > prisma/migrations/0_init/migration.sql

This creates a SQL file that reflects your current database schema.

No changes are applied to the database yet.

3. Mark the Baseline as Applied

1npx prisma migrate resolve --applied 0_init

This tells Prisma that the baseline migration is applied without modifying the database.

4. Verify Migration Status

Run:

1npx prisma migrate status

This command checks the current migration status.

In my case, I had 10 existing migrations that I needed to apply.

Or the full command that you can copy and past

1mkdir -p prisma/migrations/0_init && npx prisma migrate diff --from-empty --to-schema-datamodel prisma/schema.prisma --script > prisma/migrations/0_init/migration.sql && echo 'provider = "postgresql"' > prisma/migrations/migration_lock.toml && npx prisma migrate resolve --applied 0_init

Handling Existing Migrations

If there are existing migrations that were not properly tracked, you need to mark them as applied.

Run the following commands, replacing the migration names with your actual ones:

1for migration in 20250103175925_init 20250104081619_add_stage_model ...; do npx prisma migrate resolve --applied "$migration";done

This ensures that Prisma recognizes all migrations as applied, preserving the existing data and schema.

Make sure to add the names of the names listed in prisma migrate status

Final Thoughts

By creating a baseline migration we have achieved:

• Created a proper migration baseline
• Properly set up the PostgreSQL provider in migration lock file
• Synchronized the migration history with your current database state
• Preserved all existing data
• Enabled the ability to use prisma migrate dev for future changes

Remember, always prioritize using migrations in production environments to maintain consistency and avoid unexpected data loss.

Thanks,
Matija