Database45-70 min
Prisma Migrations in Production
Generate migrations locally, review SQL, deploy with `migrate deploy`, and use expand-and-contract steps for risky schema changes.
PrismaPostgreSQLCI/CD
Prerequisites
- A Prisma project with a committed schema.
- Separate development, staging, and production databases.
- Database backup access before migrations.
1
Plan the implementation
Start by choosing the exact page, route, API, or deployment surface you want to improve. A narrow target makes the implementation measurable and easier to verify.
- Write down the current behavior and the user-facing problem it creates.
- Pick one measurable success signal such as bundle size, latency, error rate, security coverage, or UI responsiveness.
- Identify the files, routes, providers, and environment variables involved.
- Create a rollback note before changing production-sensitive configuration.
2
Set up the required tools
Install or configure only the tools needed for this implementation. Keep config close to the feature so future developers can find the moving parts quickly.
Implementation snippet
npx prisma migrate dev --name add_feature_table
npx prisma migrate statusChecklist
- Dependencies are added to the correct workspace package.
- Environment variables are documented in `.env.example` when needed.
- Local development still starts without production-only secrets.
- The change is small enough to review in one pull request.
3
Implement the core pattern
- Create migrations locally with `prisma migrate dev`.
- Review generated SQL before committing.
- Run migrations against staging first.
- Apply production migrations with `prisma migrate deploy`.
- Use multi-step deploys for column renames, required fields, and destructive changes.
Implementation snippet
# Production deploy command
npx prisma migrate deploy
# Never use migrate dev against production.4
Handle edge cases
Checklist
- Production is backed up before risky migrations.
- Generated migration files are committed.
- No production deploy uses `migrate dev` or `db push` casually.
- Rollback or forward-fix steps are documented.
5
Verify before production
- Run the app locally and test the normal success path.
- Test one failure path, one empty state, and one slow-network or retry path.
- Run the project build and any related unit or integration tests.
- Check browser console, server logs, and network responses for hidden warnings.
- Document the final behavior, commands used, and any follow-up work.