How to use Prisma migrations to add new models on an existing Laravel-managed MySQL database without data loss

[Pavan-Kumar-KN]

What I have done so far

• The database already exists and contains data.

• I created a baseline migration in Prisma that represents the current schema:

  prisma/migrations/0_init/migration.sql
  

• I marked the baseline migration as applied.

npx prisma migrate resolve --applied 0_init

• I updated schema.prisma and added new models (new tables only, no changes to existing Laravel tables).

• When I run:

 npx prisma migrate dev --create-only --name <migration_file_name>

Prisma warns that:

• The database will be reset, or

• Data loss may occur

This is not acceptable because the database is shared and already in use.

What I want

• Prisma should treat the existing schema as baseline

• Prisma migrations should be used only for new tables / new models

• No destructive changes

• No database reset

A clean, safe workflow going forward

My Questions:

• What is the correct Prisma workflow for adding new models to an already existing Laravel-managed database?

• How should the baseline migration be created and applied so Prisma does not attempt a reset?
  After baselining, should prisma migrate dev be used for new models, or is migrate deploy the correct command?

• What is the recommended long-term migration strategy when Laravel and Prisma share the same database but Prisma is responsible for new tables?

Any official guidance or best practices for this scenario would be very helpful.

[nurul3101]

Hey @Pavan-Kumar-KN!

After you have applied have marked the baseline migration as applied via this command: npx prisma migrate resolve --applied 0_init

What happens if you run npx prisma migrate dev command after you add the new models. Is there any specific reason you need to add --create-only flag?

[Pavan-Kumar-KN]

Hi @nurul3101,
Our backend is currently built on Laravel, using MySQL (RDS), and all database migrations have been handled by Laravel so far. We’re now migrating the system feature by feature and introducing a NestJS + Prisma stack alongside it.

The issue I’m facing is that when I run prisma migrate dev, Prisma suggests resetting the database or running migrate reset, and also throws relation / foreign key errors—even though the current schema and database state are already in sync.

Since this is a shared database with existing data, resetting the DB is not an option. I’m trying to understand the correct and safe workflow to introduce Prisma migrations without affecting the existing Laravel-managed schema.

although i can push the new models using push command or deploy command but the migration file we have to maintain right
I think you got the issue now !!

[nurul3101]

Hey @Pavan-Kumar-KN, thanks for the additional context!

I understand the issue now. When you run prisma migrate dev after baselining, Prisma might be detecting drift between your baseline migration and the actual database state, which triggers the reset warning.

Here's what I'd recommend:

1. After marking the baseline as applied, ensure your schema.prisma exactly matches the current database state (including all Laravel tables). You can use prisma db pull to verify this.
2. Then add only your new models to schema.prisma (the ones Prisma will manage).
3. Run prisma migrate dev --name add_new_models without the --create-only flag. This should generate a migration file with only the new tables, since the baseline is already marked as applied.
   The relation/foreign key errors you're seeing suggest there might be a mismatch between what's in your baseline migration and what's actually in the database.

Regarding migration files: Yes, you should maintain them! Using prisma db push skips the migration history entirely, which isn't ideal for production workflows. Once your baseline is properly set up, prisma migrate dev should work cleanly for new additions.

Let me know if you still see the reset warnings after ensuring your baseline matches the DB state exactly!

[Pavan-Kumar-KN]

Hi @nurul3101 I have tried as you said but in the last stage getting this issue

Loaded Prisma config from prisma.config.ts.

Prisma schema loaded from prisma\schema.prisma.
Datasource "db": MySQL database "searchy" at "localhost:3306"

Drift detected: Your database schema is not in sync with your migration history.

The following is a summary of the differences between the expected database schema given your migrations files, and the actual schema of the database.

It should be understood as the set of changes to get from the expected schema to the actual schema.

[+] Added tables
  - TestUser

[*] Changed the `five_minute_journals` table
  [*] Altered column `user_type` (default changed from `Some(Value(String("AppModelsUser")))` to `Some(Value(String("App\\Models\\User")))`)

[*] Changed the `goals` table
  [*] Altered column `user_type` (default changed from `Some(Value(String("AppModelsUser")))` to `Some(Value(String("App\\Models\\User")))`)

[*] Changed the `notes` table
  [*] Altered column `user_type` (default changed from `Some(Value(String("AppModelsUser")))` to `Some(Value(String("App\\Models\\User")))`)

[*] Changed the `todos` table
  [*] Altered column `user_type` (default changed from `Some(Value(String("AppModelsUser")))` to `Some(Value(String("App\\Models\\User")))`)

We need to reset the MySQL database "searchy" at "localhost:3306"

You may use prisma migrate reset to drop the development database.
All data will be lost.

Note: I’ve now taken a SQL dump from the live database and am running it inside a Docker container.

[nurul3101]

Ok, this issue happens when your actual database schema has changed in a way that Prisma's migration history doesn't reflect. This commonly occurs when manual changes were made to the database, or another tool (like Laravel migrations) modified the schema.

Could you try this solution?

First, run npx prisma db pull to update your schema.prisma file so it accurately reflects the current database state, including any tables or column changes made outside Prisma. Next, create a migration file that records these changes without actually applying them (since they already exist in the database). You can do this with npx prisma migrate dev --create-only --name fix_drift. If that still forces a reset, use the migrate diff command to generate the SQL manually, it could look something like this:

npx prisma migrate diff \\
  --from-migrations ./prisma/migrations \\
  --to-schema-datamodel prisma/schema.prisma \\
  --script > prisma/migrations/$(date +%Y%m%d%H%M%S)_fix_drift/migration.sql

Then mark it as applied: npx prisma migrate resolve --applied fix_drift

After completing these steps, run npx prisma migrate dev again. It should hopefully now report that everything is in sync with no reset required.

[BertramYe]

actually I meet the same issue for the prisma 7, as when I create an schema from scratch , an after the first times initial migrate, it run successfully, and then I am going to add some of the fields in the schema for exised tables, and also for the new added fields, there were not any bad effect or foreign keys was added, just an option normal feild, and then when I run the command with the npx prisma migrate dev --name add_new_feilds , which show the same issue like above, it won't help create the new migration files, but to let me reset the database, just like : You may use prisma migrate reset to drop the development database.All data will be lost.

[BertramYe]

hello @nurul3101 , I found that this case was caused by the shadowDatabaseUrl config, according to the offiocial docs here: https://www.prisma.io/docs/orm/prisma-migrate/understanding-prisma-migrate/shadow-database#cloud-hosted-shadow-databases-must-be-created-manually, for me, when I use the primsa with the postgresql , just according to the doc to auth current use the auth, which would be ok , just like here below:

as the current db connection user have the create/drop db auth , it will help create the shadow db with the randon db name, but when I going to point an specified db as the shadow db by the shadowDatabaseUrl, it will always cause the error like below （the Schema Drift）with the same user and have the same auth of the DB create and also have set the shadow db onwner as the same user in the db connection
and the shadowDatabaseUrl configs' user.

so to resolve the issue caused by when I config shadowDatabaseUrl, except removing this config, what kind of the actual the db auth for the user of the shadowDatabaseUrl needed, although I have tried with the CREATEDB and shadow-db-owner-changed for the postgresql?

[nurul3101]

I didn't understand your question. Can you please elaborate on what you mean by

current db connection user have the create/drop db auth

Are you referring to permissions required for the db user?

[BertramYe]

Yeah ,sure, found that just give the db user the auth of the DBCreate without the shadow db, the issue can be resolved,as it will help automatically create and delete the shadow db ,but when I specify an empty db as an shadow db in the configuration and make the db's owner as the same user,then grant all privileges of the db to the user, it doesn't works,so I just want to figure when I configure and specify an shadow db,what actually privileges/auth,the user actually needed?

[tamish-max]

For a shared existing DB, the key point is: prisma migrate dev is a development workflow and is not something I would run against the shared Laravel/RDS database. It uses a shadow database and will warn/reset when it sees drift.

The safe long-term flow is usually:

1. prisma db pull until schema.prisma exactly matches the current DB
2. create a baseline with prisma migrate diff --from-empty --to-schema-datamodel prisma/schema.prisma --script > prisma/migrations/0_init/migration.sql
3. mark that baseline as applied with prisma migrate resolve --applied 0_init
4. create future Prisma-managed tables in a separate dev DB with prisma migrate dev
5. apply those new migrations to shared/prod with prisma migrate deploy

If you still get reset/drift warnings after baselining, it usually means either the baseline does not exactly match the real DB, or the shadow DB setup/permissions are off.

[GitNimay]

This is a well-documented but easy to misconfigure scenario. The warning you are seeing is the key diagnostic, so understanding exactly why it appears will clarify which step needs fixing.

Why Prisma is still warning about data loss

When you run prisma migrate dev, Prisma compares your current schema.prisma against the migration history it tracks in _prisma_migrations. If the diff between what the migrations would produce and what actually exists in the database is non-empty, Prisma assumes it needs to reconcile that gap, which triggers the reset warning.

The most common cause in your situation is that the baseline migration SQL in 0_init/migration.sql does not exactly match the actual database schema. Even small differences, like missing indexes, slightly different column defaults, or tables Prisma introspected incorrectly, cause the drift detection to fire.

Fixing the baseline

Before adding any new models, verify the baseline is accurate by running:

npx prisma migrate diff \
  --from-migrations prisma/migrations \
  --to-schema-datasource prisma/schema.prisma \
  --shadow-database-url "postgresql://user:pass@localhost/shadow_db"

If this outputs any SQL, your baseline does not match reality. The safest way to regenerate an accurate baseline is:

npx prisma db pull

This overwrites your schema.prisma with what is actually in the database. Then take that output as your 0_init/migration.sql by doing:

npx prisma migrate diff \
  --from-empty \
  --to-schema-datasource prisma/schema.prisma \
  --script > prisma/migrations/0_init/migration.sql

Then mark it applied again:

npx prisma migrate resolve --applied 0_init

Adding new models safely after a clean baseline

Once the baseline is accurate and drift-free, your workflow for new Prisma-only tables is:

npx prisma migrate dev --create-only --name add_new_table

Review the generated SQL to confirm it only contains CREATE TABLE statements for your new models and nothing touching existing tables. Then apply it:

npx prisma migrate deploy

Use migrate deploy rather than migrate dev in shared or production-adjacent environments. migrate dev is designed for development and will attempt schema reconciliation aggressively. migrate deploy only runs pending migrations that have not yet been applied, with no drift checking or reset logic.

Long-term workflow for Laravel and Prisma sharing the same database

Keep a strict ownership boundary. Laravel owns its tables completely and Prisma should never reference them in schema.prisma unless you are treating them as read-only. The cleanest way to enforce this is to keep Laravel-managed tables out of your Prisma schema entirely and only define your new Prisma-owned models.

// Only define models Prisma is responsible for
// Do not add models for Laravel tables

model PrismaOwnedTable {
  id        Int      @id @default(autoincrement())
  createdAt DateTime @default(now())
}

If you need to query Laravel tables from Prisma, use prisma db pull to introspect them into a separate read-only schema file for reference, but do not include them in the schema you run migrations against.

Your migration commands by environment should be:

# Local development - creates migration file only, you review before applying
npx prisma migrate dev --create-only --name descriptive_name

# Staging and production - applies pending migrations only, no destructive logic
npx prisma migrate deploy

Never run prisma migrate dev against a shared database. It is built for local development workflows and its reconciliation behavior is exactly what is causing your warnings.

[gajendrachary]

This is a classic Prisma baselining + shadow database drift scenario. Here's the correct step-by-step approach to add new Prisma models to a Laravel-managed MySQL database without any data loss or resets:

---

The correct workflow:

Step 1: Make sure your baseline is solid

Your baseline migration (0_init) must exactly match the current live database schema. The most reliable way:

# Pull the exact current schema from your live DB into schema.prisma
npx prisma db pull

# Then generate your baseline SQL from this
npx prisma migrate diff \
  --from-empty \
  --to-schema-datamodel prisma/schema.prisma \
  --script > prisma/migrations/0_init/migration.sql

# Mark it as already applied
npx prisma migrate resolve --applied 0_init

Step 2: Add your new models to schema.prisma

Only add the new tables — do NOT modify or remove existing Laravel-managed table definitions.

Step 3: Use migrate dev --create-only to generate migration SQL (no auto-apply)

npx prisma migrate dev --create-only --name add_new_models

This creates prisma/migrations/<timestamp>_add_new_models/migration.sql. Review the file to confirm it only contains CREATE TABLE statements for your new models — nothing touching existing tables.

Step 4: Apply the migration directly (safe)

npx prisma migrate deploy

migrate deploy applies pending migrations without the shadow database drift check — this is the key difference. It is safe for production and will not prompt a reset.

---

Why migrate dev keeps warning about drift:

migrate dev uses a shadow database to detect if the current DB differs from what the migration history would produce. Since Laravel created tables that Prisma has no migration record for, it detects "drift" and warns. The solution is:

• Use migrate dev --create-only to just generate SQL (skip the shadow DB apply)
• Use migrate deploy for actual application (no drift check)

---

This workflow is officially recommended by Prisma for existing databases and shared databases not fully owned by Prisma. Hope this resolves your issue!