Who in their right minds where thinking this was a good idea??

[5m1Ly]

Question

When you rename a model in your Prisma schema (and likely also when renaming fields/columns), running prisma migrate dev generates a migration that issues a DROP TABLE on the old table name followed by a CREATE TABLE for the new name... instead of an ALTER TABLE ... RENAME TO statement.

This means that if this migration is applied to a production database (e.g. via prisma migrate deploy) without careful manual review, all existing data in that table is silently and permanently deleted. There is no warning, no prompt, and no safeguard built into the migration process to prevent this from happening.

So therefore I'm asking again, Who in their right minds where thinking this was a good idea??

How to reproduce (optional)

1. Set up a Prisma project with an existing model, e.g.:

model User {
    id   Int    @id @default(autoincrement())
    name String
}

2. Run prisma migrate dev to apply the initial migration.
3. Rename the model in schema.prisma:

model Account {
    id   Int    @id @default(autoincrement())
    name String
}

4. Run prisma migrate dev again and inspect the generated SQL.

Observed: The migration contains DROP TABLE "User" followed by CREATE TABLE "Account".
Expected: The migration contains ALTER TABLE "User" RENAME TO "Account".

Expected behavior (optional)

Prisma Migrate should detect that a model rename has occurred and generate an ALTER TABLE ... RENAME TO ... statement, preserving all existing data. At a minimum, if Prisma cannot reliably detect renames, it should:

• Warn the developer explicitly in the CLI that data loss will occur, and
• Require explicit confirmation before proceeding (similar to how some tools require typing DROP to confirm destructive operations).

The current behavior is a silent data loss footgun with no guardrails for production use.

Migration Data-Loss Detection Pipeline + Generic Explanation

A CI pipeline that runs on every pull request that modifies migration files, before those migrations are ever applied to a real environment. It is entirely self-contained, no access to production or staging databases is required.

The pipeline works in two passes against a fresh, isolated database:

Pass 1: Establish baseline

1. Spin up a temporary database.
2. Apply all migrations that are already deployed on the target environment (the baseline state).
3. Seed the database with synthetic data: 1-2 deterministic rows per table, with every column, including nullable ones populated with a non-null value. This ensures any destructive change will be caught, not just changes to required columns.
4. Take a full snapshot of the seeded data (all rows, all columns, all tables).
5. Also snapshot the database schema (table names, column names, data types, nullability).

Pass 2: Apply and verify

1. Apply only the new migrations from the current branch.
2. Take a second snapshot of data and schema.
3. Compare the two snapshots.

---

What Gets Detected

1. Data loss: any row that existed before the migrations but is missing or corrupted after. Reported per table as a loss percentage.
2. Column loss: any column that existed before but is absent or entirely null after.
3. Probable renames: this is the novel part. Because Prisma emits DROP + CREATE for renames, the comparison sees a table/column disappear and a new one appear. A structural similarity scorer is run over every (disappeared, appeared) pair using signals like:

• Overlap between the old and new column name sets (Jaccard index)
• Overlap of column names and data types
• Whether the new table/column is empty after migration (the data went nowhere)
• Levenshtein edit distance between the old and new names

If the similarity score crosses a threshold (≥ 60 %), the pair is flagged as a probable rename candidate rather than silently treated as an intentional drop. The migration is still blocked: the developer must resolve it by either adding @@map/@map to the Prisma schema (which causes Prisma to emit a proper RENAME instead) or manually editing the migration SQL to use ALTER TABLE ... RENAME.

---

Output

A coverage report is produced showing every table with:

• Row count before and after
• Data loss percentage
• Any columns that disappeared or went null
• Any rename candidates with confidence score and the signals that triggered it

Severity levels:

• OK: no loss, no renames → pipeline passes
• Warning: partial loss or a probable rename → pipeline fails with an actionable message
• Error: total or near-total loss → pipeline hard-fails

---

Why This Matters

The standard Prisma workflow gives no feedback about data loss until the migration runs against real data. This pipeline moves that feedback to the pull request review stage, before anything reaches staging or production, and specifically surfaces the rename footgun that Prisma's generation creates by design.

[yudin-s]

This is one of the places where Prisma Migrate is intentionally conservative: it diffs the Prisma schema, but it cannot always know that a model rename is the same database table rather than “drop one model, create another”.

For a pure Prisma-level rename where the underlying table should keep its old name, use mapping:

model Account {
  id   Int    @id @default(autoincrement())
  name String

  @@map("User")
}

That renames the model in Prisma Client while keeping the database table as User.

If you really want to rename the physical table too, create the migration and edit the generated SQL before applying it:

ALTER TABLE "User" RENAME TO "Account";

Same idea for columns: use @map if only the Prisma field name changes, or edit the migration to use ALTER TABLE ... RENAME COLUMN ... if the database column should be renamed.

I agree this is something you have to be very careful with. The safe workflow is: generate migration, review the SQL, replace destructive drop/create statements with rename statements when it is a rename, then apply. Never deploy a generated migration involving renames without reading it.

[GitNimay]

Small categorization note: this is probably better tracked as a feature request or migration safety discussion than as a normal question.

The behavior is frustrating, but the root cause is that Prisma Migrate is doing schema diffing, not semantic refactoring detection. When the old model name disappears and a new model name appears, Prisma cannot reliably know whether that was intended to be a rename, a table replacement, a split, a merge, or an intentional drop and recreate. So the generated migration represents what the diff engine can prove: one table removed, one table added.

That said, I agree that this is a dangerous footgun, especially because the safe intent is common. A model rename is not an exotic operation, and a generated migration that drops a populated table is something teams should be forced to notice before it gets anywhere near production.

The current safe workflow is to treat renames as migrations that require human edited SQL. For example, if the generated migration contains this kind of change:

DROP TABLE "User";

CREATE TABLE "Account" (
  "id" SERIAL NOT NULL,
  "name" TEXT NOT NULL,

  CONSTRAINT "Account_pkey" PRIMARY KEY ("id")
);

then the migration should be edited to a real table rename instead:

ALTER TABLE "User" RENAME TO "Account";

For a column rename, the same idea applies:

ALTER TABLE "Profile" RENAME COLUMN "biograpy" TO "biography";

If the goal is only to rename the Prisma Client API while keeping the physical database table name unchanged, use mapping instead:

model Account {
  id   Int    @id @default(autoincrement())
  name String

  @@map("User")
}

And for fields:

model Account {
  id       Int    @id @default(autoincrement())
  fullName String @map("name")

  @@map("User")
}

That avoids changing the database object name at all. Prisma Client sees Account and fullName, while the database still has the "User" table and "name" column.

For production use, I would not rely on generated migrations being safe by default. The safer policy is:

1. Generate the migration.
2. Review the SQL.
3. Replace destructive rename shaped diffs with ALTER TABLE RENAME or ALTER TABLE RENAME COLUMN.
4. Run the migration against a disposable database with representative seeded data.
5. Only then allow it into deploy.

The CI idea you described is a good direction. A migration verification job that applies the already deployed baseline, seeds deterministic data, applies only the new migrations, and then compares before and after state would catch exactly this class of issue. The rename similarity scoring is also useful because it can distinguish “this looks like an intentional drop” from “this looks like the same table under a new name.”

I would frame the requested improvement as two separate things:

1. Rename intent support

Prisma would need some way to express or infer rename intent, for example an interactive prompt during migration generation or an explicit rename annotation/workflow. Without that, the engine has no reliable semantic signal.

2. Stronger destructive migration guardrails

Even if automatic rename detection is not implemented, dropping a table or column that may contain data should be surfaced very loudly during migration generation, and teams should have a first class way to fail CI on destructive operations.

So the practical answer today is: yes, manually edit the migration or use @@map and @map, and do not deploy unchecked generated SQL. But I think the feature request is valid. The default behavior may be explainable from a diffing perspective, but the developer experience around this could definitely be safer.

[aymenhmaidiwastaken]

This is intentional (though frustrating). Prisma Migrate diffs the schema declaratively — it sees "model A is gone, model B is new" rather than "model A was renamed to B". It cannot infer renames.

The workflow Prisma expects:

1. Run prisma migrate dev --create-only — this generates the SQL file without applying it
2. Open the generated migration file
3. Replace the DROP TABLE + CREATE TABLE with ALTER TABLE ... RENAME TO
4. Run prisma migrate dev to apply the edited migration

-- Replace this:
-- DROP TABLE "OldName";
-- CREATE TABLE "NewName" (...);

-- With this:
ALTER TABLE "OldName" RENAME TO "NewName";

This is documented but easy to miss. The --create-only flag is key — it gives you a chance to review and edit before anything touches the database.

For field/column renames, same pattern:

ALTER TABLE "MyTable" RENAME COLUMN "oldName" TO "newName";

It's not ideal that the default generated migration is destructive, but the reasoning is that Prisma can't reliably distinguish a rename from a delete+create at the schema diff level. Always use --create-only for migrations that involve renames.

[JosephHampton]

Yeah this is expected, even though it's a nasty footgun. Prisma Migrate is declarative, it diffs the desired schema against the current one, but it has no way of knowing you renamed Foo to Bar versus deleted Foo and added Bar. Both produce the exact same end state, and with no rename info the diff that looks safe to it is DROP + CREATE, which for your data is the opposite of safe.

The intended way to do any rename is to generate the migration but not run it, then edit the SQL yourself:

prisma migrate dev --name rename_foo_to_bar --create-only

--create-only writes the migration file without applying it. Open it and swap the DROP/CREATE for what you actually meant:

-- what Prisma generated
-- DROP TABLE "Foo";
-- CREATE TABLE "Bar" (...);

-- what you actually want
ALTER TABLE "Foo" RENAME TO "Bar";
-- or for a column
ALTER TABLE "Bar" RENAME COLUMN "oldName" TO "newName";

Then apply it with prisma migrate dev locally or prisma migrate deploy in prod. Since you hand wrote the ALTER, the history stays consistent and nothing gets dropped.

Rule of thumb I go by: any rename gets --create-only plus a manual edit, and never let an auto generated rename migration reach prod without reading it first. Like you found, there's no guard rail built in, so --create-only is the guard rail you add yourself.

If that sorts it, a tick as the accepted answer would be appreciated.