Migrate db in Production fly.io
Given that I have a wasp app I deployed to fly.io, what are the steps I need to do to make sure changes to entity schemas are reflected in Production database?
Additional questions:
1. Has anyone deployed db changes to an already deployed app and can share common pitfalls?
2. Is there a wasp db migrate-dev equivalent such as wasp db migrate-prod?
3 Replies
Hi @OrBlatt. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
To reflect changes to entity schemas in your production database on fly.io, you would typically follow these steps:
1. Update your entity schemas in your local development environment.
2. Run
wasp db migrate-dev to apply the changes and create a new initial migration. This command synchronizes the development database with the current state of the schema (entities). If there are any changes in the schema, it generates a new migration and applies any pending migrations to the database [^1^].
3. Deploy your updated code to your production environment on fly.io.
However, there are some additional considerations when dealing with production databases, especially when it comes to data migrations and seeding.
For example, you might need to seed your production database. This process involves pointing your local app to use the production DB and opening a tunnel towards the production DB so the local app can connect to it. You can use the fly proxy 5432 -a <postgres-app-name> command to open a tunnel to the production DB. Then, you can run wasp db seed to populate the production DB [^5^].
As for common pitfalls, one issue that has been reported is forgetting to run wasp db migrate-dev after making changes to entity schemas. This can lead to issues where the production database does not reflect the latest schema changes [^4^].
Currently, there is no wasp db migrate-prod command. The wasp db migrate-dev command is used for both development and production environments. However, you should be careful when running this command in a production environment, as it could potentially lead to data loss if not used correctly.
[^1^]: (https://wasp-lang.dev/docs/general/cli#database-commands)
[^4^]: (https://discord.com/channels/686873244791210014/1217295340785635418)
[^5^]: (https://github.com/wasp-lang/wasp/issues/1464)
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @OrBlatt, 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?Anyone experienced data loss after entity schema update or know how to prevent it? 🙏
We have the
migrations dir with migration scripts because we want to keep our production DB in sync with what we have in development.
Data loss is not common during schema migrations in my experience. You get reminded by Prisma as well if migration will be destructive - deleting a field or something similar.
In any case, you should have DB backups to be extra safe from which you can restore your DB if something does go wrong. Fly does this for you daily: https://fly.io/docs/postgres/managing/backup-and-restore/#listing-snapshots