Workflow for getting your DB schema into production when using separate databases
Let's say I use separate databases in development and production.
How do you push your schema changes into your production DB? Do you just run
push
or migrate
after pulling the latest code from GitHub?6 Replies
You chose to compile with the bot. One moment while I piece together your answer…
When deploying database schema changes to production with Prisma, there are two main approaches depending on your database type and requirements:
Using
prisma migrate deploy
(Recommended for relational databases)
For relational databases (PostgreSQL, MySQL, SQL Server), the recommended workflow is:
1. Develop and test schema changes locally using prisma migrate dev
2. Commit the generated migration files in the prisma/migrations
folder to your repository
3. In your CI/CD pipeline or production environment, run prisma migrate deploy
This approach is considered best practice because:
- It applies pending migrations in a safe, controlled manner
- It tracks migration history in both the codebase and database
- It doesn't reset your production database
As noted in the documentation, migrate deploy
should be part of an automated CI/CD pipeline rather than run manually from a local environment:
"Ideally, migrate deploy
should be part of an automated CI/CD pipeline, and we do not generally recommend running this command locally to deploy changes to a production database." Deploy database changes with Prisma Migrate
Using prisma db push
(For MongoDB or PlanetScale)
For MongoDB or PlanetScale databases, use prisma db push
instead:
This is necessary because:
- MongoDB doesn't support migrations in the same way as relational databases
- PlanetScale has its own branching model that conflicts with Prisma's migration history approach
Example CI/CD Implementation
You can implement this in GitHub Actions with a workflow like:
This workflow will automatically run when changes are pushed to the migrations directory, applying them to your production database. Deploy database changes with Prisma Migrate
Important Considerations
- Never store production database URLs locally
- Ensure your DATABASE_URL
is set as a secret in your CI/CD environment
- For multiple databases, you can create custom scripts in your package.json to handle migrations for each database separately How to use multiple databases in a single app
Remember that migrate deploy
uses advisory locking to prevent multiple commands from running simultaneously, which is important when merging multiple pull requests in quick succession.
🤔 Alright, thanks for letting us know that there's still some help needed. A team member will reply to you shortly.
In the meantime, please let us know any additional info, questions, or which parts of the answer may need clarification.@Prisma AI Help Can you link me to where you got this information from? It looks incomplete
It would be great if a human can tell me briefly about the most simple approach here.
Ok looks like prisma migrate deploy is what I need. Where can I execute this if I don't have a CI/CD integration and run everything manually on a VPS?
Would I simply set up my own build command that runs
prisma migrate deploy && next build
?I think you have to provide the database url and then migrate the database based on your schema....Correct me if I am wrong
I'm wondering about the workflow. At what step does that happen? Do I just SSH into my server (if I use a VPS) and run
migrate deploy
after pulling from Github?You can indeed create a custom build command that includes both database migrations and application builds.
Something like this: https://www.prisma.io/docs/orm/prisma-client/deployment/serverless/deploy-to-vercel#cicd-workflows might work
Deploy to Vercel | Prisma Documentation
Learn how to deploy a Next.js application based on Prisma Client to Vercel.
Thank you