MergeBrake
Prisma migration guide

How to safely drop a Prisma column without breaking production.

A Prisma DROP COLUMN migration is safe only after deployed app code has stopped reading and writing that column. The failure mode is usually an app-code reference hidden behind @map, a serializer, a background job, or raw SQL.

1. Expand

Stop app reads first

Deploy application code that no longer reads or writes the Prisma field. Keep the database column in place while old instances drain.

2. Verify

Check aliases and raw SQL

Search for the mapped database name, Prisma field name, serializers, API responses, background jobs, and SQL strings.

3. Contract

Drop in a later deploy

Once no deployed code depends on the column, ship the DROP COLUMN migration as its own contract step.

The risky Prisma pattern

Prisma field names often differ from database column names. This is common when the database uses snake_case and the application uses camelCase: 

model User {
  id       String @id
  fullName String @map("full_name")

  @@map("users")
}

A generated migration may remove users.full_name, while TypeScript still reads user.fullName. A plain SQL linter can see the destructive DDL, but it cannot always tell whether the app still reaches that column through Prisma.

What MergeBrake checks in the PR

  • Parses the Postgres migration with libpg_query.
  • Expands users.full_name into Prisma symbols such as fullName.
  • Finds references in TypeScript, raw SQL, serializers, and jobs.
  • Posts a sticky PR comment with a safe rollout recipe.