Drift-free git feature branch switching ?

[KaKi87]

Question

When working on multiple features at 1 branch per feature, each with a different database change, how to switch between branches without being blocked by drift issues while preserving the dev database's data ?

How to reproduce (optional)

1. Start on branch main with a dev database in sync with schema ;
2. Create a new branch ft/some-enhancement, make schema changes and run prisma migrate dev successfully ;
3. Go back on branch main ;
4. Create a new branch ft/some-other-enhancement, make schema changes and run prisma migrate dev, which will fail with the drift detected error.

Expected behavior (optional)

This is expected of course, but ideally I'd like a way to "stash" the migration created in ft/some-enhancement so the database gets back to its original state as I go back to main and I can make a drift-free migration on ft/some-other-enhancement. Alternatively, a flag to skip migrations from a different branch when generating new ones.

Information about Prisma Schema, Client Queries and Environment (optional)

generator client {
  provider     = "prisma-client"
  output       = "../../src/generated/prisma"
  moduleFormat = "cjs"
}

datasource db {
  provider = "postgresql"
}

• OS: Mac v26

• Database: PostgreSQL v18

• Node.js version: 24.12.0

• prisma : 7.7.0
  @prisma/client : 7.7.0
  Operating System : darwin
  Architecture : x64
  Node.js : v24.12.0
  TypeScript : 6.0.2
  Query Compiler : enabled
  PSL : @prisma/prisma-schema-wasm 7.6.0-1.75cbdc1eb7150937890ad5465d861175c6624711
  Schema Engine : schema-engine-cli 75cbdc1eb7150937890ad5465d861175c6624711 (at node_modules/@prisma/engines/schema-engine-darwin)
  Default Engines Hash : 75cbdc1eb7150937890ad5465d861175c6624711
  Studio : 0.27.3

---

Thanks

[debjit450]

This is not really something Prisma can safely solve by skipping migrations from another branch.

After running migrate dev on ft/some-enhancement, your development database contains that branch's migration in _prisma_migrations. When you switch back to main or to another feature branch, the migration file is no longer present in the checked-out migration history, while the database still says it was applied. Prisma correctly reports a migration history conflict.

For disposable development data, the normal workflow is:

npx prisma migrate reset

and then restore predictable development data through a seed script.

If the development data must be preserved independently on each branch, the practical solution is to use one development database per branch rather than switching incompatible migration histories against the same database.

For example:

main                  -> app_dev_main
ft/some-enhancement   -> app_dev_some_enhancement
ft/some-other-change  -> app_dev_some_other_change

Then each branch uses its own DATABASE_URL:

# ft/some-enhancement
export DATABASE_URL="postgresql://postgres:postgres@localhost:5432/app_dev_some_enhancement"
npx prisma migrate dev

# ft/some-other-enhancement
export DATABASE_URL="postgresql://postgres:postgres@localhost:5432/app_dev_some_other_enhancement"
npx prisma migrate dev

With Prisma 7, this can remain a normal environment-variable change because the URL is read by prisma.config.ts:

import "dotenv/config";
import { defineConfig, env } from "prisma/config";

export default defineConfig({
  datasource: {
    url: env("DATABASE_URL"),
  },
});

If a new feature branch should begin with the current development data, create its database from a dump of the base branch database before running the feature migration:

createdb app_dev_some_enhancement

pg_dump --format=custom app_dev_main > app_dev_main.dump
pg_restore --no-owner --dbname=app_dev_some_enhancement app_dev_main.dump

export DATABASE_URL="postgresql://postgres:postgres@localhost:5432/app_dev_some_enhancement"
npx prisma migrate dev

That gives each branch its own schema state, migration table, and preserved local data, without fighting Prisma's migration history checks.

I would avoid trying to manually delete rows from _prisma_migrations, selectively skip migrations, or run ad-hoc rollback SQL when switching branches. A successful migration can also contain destructive or data-transforming changes, so reverting only migration bookkeeping would leave the schema or data inconsistent.

So the two sane workflows are:

1. Disposable local data: one database, migrate reset plus seeding when switching incompatible branches.
2. Valuable branch-specific local data: one database per branch, optionally initialized from a dump of the base development database.

[phlppgdfry]

This is a real pain point with Prisma's migration workflow. There are a few strategies that work well in practice:

Strategy 1: One dev database per feature branch (cleanest)

The most friction-free solution is to use a separate database per branch. With PostgreSQL this is easy:

# In your .env or .env.local per branch
DATABASE_URL="postgresql://user:pass@localhost:5432/myapp_ft_some_enhancement"

With tools like dotenv-cli + per-branch .env files, or a tool like direnv, switching branches also switches your DB automatically. Each branch gets its own clean migration history with no drift.

Services like Neon (branching databases) or PlanetScale (schema branches) make this even smoother if you're not running locally.

Strategy 2: Reset and re-migrate on switch

If you want to keep a single DB, the workflow is:

# Leaving ft/some-enhancement, going back to main:
npx prisma migrate reset --skip-seed  # resets DB to baseline
git checkout main

# Going to ft/some-other-enhancement:
git checkout ft/some-other-enhancement
npx prisma migrate dev  # applies only this branch's migrations

prisma migrate reset drops all data and re-runs from scratch, which is the "stash" equivalent for your DB. The downside is losing dev data — hence keeping seed scripts (prisma/seed.ts) is important so you can repopulate quickly.

Strategy 3: Shadow database + manual baseline

For preserving data, this is more complex but possible:

1. Before switching branches, create a dump of the current DB:

   pg_dump myapp_dev > /tmp/branch_ft_some_enhancement.sql

2. Switch branches and reset:

   git checkout main
   npx prisma migrate reset --skip-seed
   # restore main's data if you have a dump

3. When switching back:

   git checkout ft/some-enhancement
   npx prisma migrate reset --skip-seed
   psql myapp_dev < /tmp/branch_ft_some_enhancement.sql

This is scriptable with a small shell helper.

Strategy 4: --skip-generate + manual drift resolution

If you really want to avoid reset, you can use prisma migrate resolve to tell Prisma a migration was already applied:

npx prisma migrate resolve --applied "20240101000000_ft_some_enhancement_change"

But this is fragile — you're lying to Prisma about the DB state, which can cause worse drift later.

Recommendation

For active feature branch development: Strategy 1 (per-branch database) is by far the smoothest. If you're on local Postgres, creating a new DB costs almost nothing:

createdb myapp_$(git branch --show-current | tr '/' '_')

Pair with a .envrc (direnv) that sets DATABASE_URL based on the current branch name.

[KaKi87]

Any non-AI response from people who either maintain Prisma or actually manage this use case in a professional environment, please ?

[ELHart05]

There is no built-in "stash a migration" feature, and a flag to skip another branch's migrations isn't coming, because the conflict isn't in the files, it's in the database. When migrate dev runs on ft/some-enhancement it inserts a row into the _prisma_migrations table. When you check out ft/some-other-enhancement, that migration file is gone from disk but the row is still in the DB, so Prisma sees an applied migration with no corresponding file and reports drift. That check is doing its job, so the only real fixes are at the database level, not the CLI level.

In practice the workflow that actually holds up day to day, and what I run, is one dev database per branch. A local Postgres database is basically free to create, and since prisma.config.ts already reads the URL from an env var, switching branches just means switching which database that var points at. Nothing about your schema or migration history has to change.

// prisma.config.ts
import "dotenv/config";
import { defineConfig, env } from "prisma/config";

export default defineConfig({
  schema: "prisma/schema.prisma",
  migrations: { path: "prisma/migrations" },
  datasource: {
    url: env("DATABASE_URL"),
  },
});

The piece that makes this painless is wiring DATABASE_URL to the current branch name automatically. With direnv and a .envrc (gitignored):

# .envrc
export DATABASE_URL="postgresql://postgres:postgres@localhost:5432/myapp_$(git branch --show-current | tr '/-' '__')"

Now cd into the repo or switch branches and the var follows. First time on a branch you just create the DB and migrate:

createdb "myapp_$(git branch --show-current | tr '/-' '__')"
npx prisma migrate dev

Each branch gets its own migration history and its own data, no drift, no resets, and merging a feature to main is a normal migrate dev against the main database because that branch already has only the migrations it should. If you want a new branch to start from your current main data instead of empty, seed it from a dump once:

pg_dump --format=custom myapp_main > /tmp/base.dump
createdb myapp_ft_some_enhancement
pg_restore --no-owner --dbname=myapp_ft_some_enhancement /tmp/base.dump

If the dev data is genuinely disposable, the simpler path is a single database plus prisma migrate reset on every switch. reset drops the database, replays the checked-out migration history from scratch, then runs your seed (docs). Keep a real prisma/seed.ts so this is a one-liner:

git checkout ft/some-other-enhancement
npx prisma migrate reset   # drops, replays this branch's migrations, reseeds

Two things to skip:

• The shadow database does not solve this. It's a temporary DB that migrate dev creates and deletes on every run purely to validate the current migration history and check for data loss. It only looks at your current branch's history, so it does nothing for cross-branch drift (docs).
• Don't hand-edit _prisma_migrations or migrate resolve --applied your way out of it. A migration can carry destructive or data-transforming SQL, so faking the bookkeeping leaves the schema and data out of sync and you get worse drift later.

One more tactical note: if you create a migration but want to inspect or tweak the SQL before it touches your DB, npx prisma migrate dev --create-only writes the migration file without applying it. Doesn't change the branch story, but it's handy when you're iterating.

Per-branch databases is the one that scales to a team without anyone thinking about drift. If that sorts it for you, mark it as the answer.

[tianalemesle]

the conflict isn't in the files, it's in the database

Still, it would be so nice if database connectors had a "stash" feature.

Or, for Prisma, just down migrations would already be a great step...

[ELHart05]

hmmmmm, welp it seems like a good issue to flag and PR yet it's totally a tough work to do XD

[Krishna11118]

This is a real pain point when working with Prisma migrations across feature branches. Here are two solid approaches:

Option 1: Use a separate database per branch (recommended)

The cleanest solution is giving each feature branch its own dev database. With Docker this is trivial:

# .env.branch (gitignored, set per branch)
DATABASE_URL="postgresql://user:pass@localhost:5432/mydb_$(git branch --show-current)"

Each branch gets its own isolated database — zero drift by design.

Option 2: Reset + re-migrate on branch switch

Add a git post-checkout hook at .git/hooks/post-checkout:

#!/bin/bash
IS_BRANCH_CHECKOUT=$3
if [ "$IS_BRANCH_CHECKOUT" = "1" ]; then
  echo "Branch switched — resetting Prisma dev database..."
  npx prisma migrate reset --force --skip-seed
  npx prisma migrate dev
fi

This automatically rolls the database back to match the current branch schema after every checkout. You lose dev data, but for a feature database that is usually fine.

Option 3: @@map to avoid rename-drops

If the drift comes from model renames generating DROP+CREATE, use @@map to keep the underlying table name stable:

model NewModelName {
  @@map("old_table_name")
}

Prisma will emit an ALTER TABLE RENAME instead of a destructive drop.

The key insight is that Prisma ties migration history to the physical database state — so the cleanest fix is decoupling databases per branch rather than trying to stash migration state.

[P4ST4S]

There is no fully drift-free way to switch between branches with different Prisma migrations while keeping one shared dev database in place. The database state and the checked-out migration history have to agree, otherwise Prisma is correct to report drift.

The safest pattern is to avoid sharing the same mutable dev database across feature branches.

What I usually recommend is one of these workflows:

1. Use one database per branch

For local development, create a database name from the Git branch:

export DATABASE_URL="postgresql://user:pass@localhost:5432/myapp_$(git branch --show-current | tr "/-" "__")"

Then each branch gets its own migration history and data. You can run:

npx prisma migrate dev
npx prisma db seed

without affecting another branch.

This is the cleanest option if you switch branches often.

2. Use disposable dev databases plus seed data

If the data can be recreated, treat the local database as disposable:

npx prisma migrate reset

and keep a good seed script.

This gives the least drift, but it does not preserve manual local data.

3. Snapshot and restore the database per branch

If you need to preserve local data, take a branch snapshot before switching:

pg_dump "$DATABASE_URL" > .db-snapshots/feature-a.sql

Then restore when coming back:

dropdb myapp_dev
createdb myapp_dev
psql myapp_dev < .db-snapshots/feature-a.sql

This works, but it is slower and more operationally heavy than one DB per branch.

4. Avoid trying to "skip" migrations from another branch

A flag that skips migrations from another branch sounds convenient, but it would be dangerous because the database would no longer represent the migration history that Prisma sees in the current checkout.

For example:

• branch A adds migration 20260601_add_table_a
• branch B does not have that migration
• the database still contains table A
• Prisma compares current migrations and actual database state
• drift is expected

At that point, the correct fix is not to ignore the drift, but to use a database whose state matches the branch.

My practical recommendation:

• For normal feature work: one local database per branch.
• For realistic data: keep a sanitized dump and restore it into each branch DB.
• For fast tests: use disposable databases and seeds.
• For production-like migration validation: use CI with a fresh database, apply migrations from scratch, and optionally test against a sanitized dump.

A simple workflow could be:

BRANCH_DB="myapp_$(git branch --show-current | tr "/-" "__")"

createdb "$BRANCH_DB" 2>/dev/null || true

export DATABASE_URL="postgresql://user:pass@localhost:5432/$BRANCH_DB"

npx prisma migrate dev
npx prisma db seed

This keeps Prisma, the migration table, and the actual schema aligned for each branch. It also avoids the hidden risk of accidentally generating a migration from a database state that belongs to another branch.

Did this resolve it? Feel free to mark as answer if so.

[KaKi87]

Here's another detail that neither this nor the other answers (which are basically suggesting the same solution) solves : Prisma generates each migration in a new directory, which doesn't get removed when swiching branches (only the SQL file inside does), which, even when the database is brand new, Prisma considers as an error. Proof that Prisma devs somehow don't have this workflow.

[P4ST4S]

@KaKi87 Yes, that is a fair point. There is a third piece here that my previous answer did not separate clearly enough:

1. the database state
2. the checked-out migration history
3. the working tree hygiene under prisma/migrations

The per-branch database pattern solves the first one. It does not automatically solve stale untracked files or folders left in prisma/migrations.

I tested the filesystem side locally with a temporary Git repo:

mkdir -p prisma/migrations/20260615123000_add_post
echo "-- experimental migration" > prisma/migrations/20260615123000_add_post/migration.sql

git status --porcelain prisma/migrations
# ?? prisma/migrations/

git switch main

git status --porcelain prisma/migrations
# ?? prisma/migrations/

So yes, Git will not remove an untracked migration directory when switching branches. Prisma then still sees that directory as part of the local migration history, even if the database is new.

The best workflow I know for avoiding both problems is not just "one database per branch", but:

one Git worktree plus one database per branch

Example:

git worktree add ../myapp-main main
git worktree add ../myapp-ft-some-enhancement ft/some-enhancement
git worktree add ../myapp-ft-some-other ft/some-other

Then each checkout has its own filesystem state:

../myapp-main/prisma/migrations
../myapp-ft-some-enhancement/prisma/migrations
../myapp-ft-some-other/prisma/migrations

And each one can point to its own database:

export DATABASE_URL="postgresql://user:pass@localhost:5432/myapp_ft_some_enhancement"
npx prisma migrate dev

That avoids the two common drift sources:

• the database migration table belongs to the branch database
• the migration directories belong to the branch checkout

If you really want to keep switching branches in a single checkout, then I would add a guard around prisma/migrations:

git status --porcelain prisma/migrations
git clean -nd prisma/migrations

Only if the dry run shows disposable generated migration folders:

git clean -fd prisma/migrations

I would not automate the destructive command blindly, because an untracked migration may be real work that has not been committed yet.

So I would revise the practical recommendation to:

• best isolation: git worktree per active branch plus one DB per branch
• acceptable single-checkout workflow: one DB per branch plus explicit cleanup of untracked prisma/migrations
• avoid: sharing one DB and one dirty working tree across incompatible migration histories

[JosephHampton]

What you're running into is that your dev database is one shared bit of mutable state, but your migrations are per branch. When you jump from branch A (whose migration is applied to the DB) over to branch B (which doesn't have that migration in its migrations/ folder), Prisma compares the live DB against B's history, sees the extra table or column, and correctly calls it drift.

There's no way to keep a single database in sync with a bunch of diverging branches at once, but you've got a few options depending on how much you care about the existing data:

Option A, a database per branch (best if you work on features in parallel). Point DATABASE_URL at a different DB name per branch, a tiny script keyed off git branch --show-current does it. Each branch's migrations apply cleanly to its own DB, no drift, data kept per branch. On local or Docker Postgres this is basically free (CREATE DATABASE feature_x). Managed Postgres with branching (Neon, Supabase, PlanetScale) automates this for you.

Option B, just reset when you switch (simplest).

prisma migrate reset

That re-applies only the current branch's migrations from scratch and runs your seed. You lose any ad hoc data, but a decent prisma/seed.ts makes that a non issue and gives you reproducible state every time. This is what most solo or small team setups do.

I'd go Option A if you're constantly hopping between feature branches, since a DB per branch kills the whole class of problem. Otherwise migrate reset plus a solid seed script, and treat the dev DB as throwaway. The data you actually care about should live in the seed, not in the database.

Hope that helps. If it does, selecting it as the answer would be great.