In production will a change to schema.prisma wipe the database?
Like it does in local dev?
4 Replies
Hi @ralph. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
No, in production, a change to schema.prisma will not automatically wipe the database.
In Wasp (and Prisma), the process for applying schema changes in production is different from local development. In local development, running commands like wasp db migrate-dev can sometimes result in destructive changes (such as dropping tables) if the migration history and the schema are out of sync, or if you reset the database. However, in production, migrations are applied using prisma migrate deploy (or a similar command), which only applies the migration steps that have been explicitly created and does not automatically wipe or reset the database.
Wasp currently recommends running migrations as a separate step before deployment, not as part of the deployed Docker container. This is to avoid running migrations on every app start and to prevent accidental data loss. The recommended approach is to run the migration in your CI/CD pipeline or manually, ensuring you have control over when and how migrations are applied. This process does not wipe the database unless your migration files themselves contain destructive changes (like drop table or drop column operations) that you have explicitly created and applied. Otherwise, schema changes alone do not trigger a database wipe in production environments We should run
- Production migrations are explicit and do not wipe the database unless the migration itself is destructive. - Wasp does not automatically reset or wipe the production database on schema changes. - Care should be taken when creating migrations to avoid destructive changes unless intended. If you need to ensure zero data loss, follow best practices for forward-only migrations and review your migration files before applying them in production. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @ralph, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?
prisma migrate deploy as a step before deployment, not as part of deployed Docker container.
In summary:- Production migrations are explicit and do not wipe the database unless the migration itself is destructive. - Wasp does not automatically reset or wipe the production database on schema changes. - Care should be taken when creating migrations to avoid destructive changes unless intended. If you need to ensure zero data loss, follow best practices for forward-only migrations and review your migration files before applying them in production. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @ralph, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?
@kapa.ai alright so if I was dumb how would I apply the changes to schema.prisma to production lol
Let me check the knowledge base for you again. One moment! :books:
----------------------
If you want to apply changes from schema.prisma to your production database in Wasp, the correct (and safe) way is to:
1. Create a migration locally after changing your entities (which updates schema.prisma) by running:
This generates a new migration file based on your changes.
2. Deploy your code and migrations to production (e.g., push to your server or CI/CD pipeline).
3. Apply the migrations to the production database. The recommended way is to run:
or, if that command is not available, run the equivalent Prisma command:
Make sure your
- Do not run wasp db migrate-dev or prisma migrate dev against your production database. These commands are meant for development and can be destructive. - Only run the migration deploy command in production, which applies the already-created migrations safely We should run
- Make migration files locally. - Deploy code and migrations. - Run migration deploy command in production with the correct
DATABASE_URL environment variable is set to your production database connection string. Do not store your production database URL in your local .env file—pass it as an environment variable or through your CI/CD secrets.
Important:- Do not run wasp db migrate-dev or prisma migrate dev against your production database. These commands are meant for development and can be destructive. - Only run the migration deploy command in production, which applies the already-created migrations safely We should run
prisma migrate deploy as a step before deployment, not as part of deployed Docker container.
If you want to do this manually (not recommended, but possible if you "were dumb"):
- You could set your DATABASE_URL to your production database locally and run migration commands, but this is discouraged because it exposes your production DB and risks accidental data loss or corruption Update the database docs on seeding the production DB on Fly.
Summary:- Make migration files locally. - Deploy code and migrations. - Run migration deploy command in production with the correct
DATABASE_URL.
This is the safe and intended workflow. Avoid shortcuts that bypass these steps, as they can lead to data loss or production outages.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @ralph, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist:
Perhaps try again in 15mins?Hey @ralph, in local dev the database is not usually wiped either, and should always ask you in advance! At any rate, when you run
wasp db migrate-dev, it will create migrations/*/migration.sql file, and those are the files that will get run when starting the app in production. You can check them to make sure no data is being lost (dropping a column or dropping a table are the most common causes for data loss)