Migrations and rollback

meridian migrate runs prisma migrate dev against your developer database with a snapshot taken first, so a half-applied migration is recoverable.

meridian migrate

The sequence is: dump the schema to .meridian/snapshots/, run the migration, and, if it fails, reset the schema and replay the snapshot automatically. A half-applied migration is worse than where you started, so the rollback is the default rather than an option.

Flag	Effect
`--skip-snapshot`	Run without a pre-migration snapshot. No rollback is possible
`--no-rollback`	Keep the snapshot but don’t restore it automatically after a failure
`--keep-snapshots <n>`	How many recent snapshots to keep after a successful run

--no-rollback is the one worth knowing: it leaves the database in its failed state and keeps the snapshot, so you can inspect what went wrong before deciding to restore. --skip-snapshot gives you neither. Snapshots are pruned only after a successful run, so a string of failures never eats the snapshot you still need. --keep-snapshots sets how many survive that pruning. --port and --env-file work here too, with the same meaning as on meridian dev.

Where a migration shows up

Every migration run is reported back to Meridian, so the app’s Developer databases page and Meridian MCP’s dev_database_migrate see the same history. A migration you ran from your terminal is visible to your team without you telling them.

​Where a migration shows up

Where a migration shows up