Database migrations for production setup
What is the recommended way to update schema changes in a production setup? I'm assuming its migrations but I'm not sure if there is equivalent of "wasp db migration-dev" for production. Can you just run "wasp db migration-dev" for production? If so, in a docker setup, would you just ssh into the server instance and run it from there after you have deployed your new code?
4 Replies
Hi @cdellinger. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
Yes, you are correct that migrations are the recommended way to update schema changes in a production setup. However, the
wasp db migrate-dev command is primarily intended for development databases. It 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 source (https://wasp-lang.dev/docs/general/cli#database-commands).
For production databases, the process is a bit different. When deploying a Wasp app, you would typically first generate deployable code using wasp build, then deploy the API server (backend), the web client (frontend), and a PostgreSQL database source (https://wasp-lang.dev/docs/advanced/deployment/manually#deploying-a-wasp-app).
In terms of applying migrations to the production database, there is currently an open issue discussing the possibility of providing direct access to Prisma CLI/commands through the Wasp CLI, which would potentially allow for commands like prisma migrate resolve to be run on production databases source (https://github.com/wasp-lang/wasp/issues/216).
As for running migrations in a Docker setup, you would typically run the migrations as part of the Dockerfile that defines the image for building the server. This would ensure that the migrations are applied each time a new instance of the server is created.
However, please note that the specifics of how to apply migrations in a production setup can vary depending on the hosting provider and the exact configuration of your application. It's always a good idea to refer to the documentation provided by your hosting provider and the Wasp documentation for the most accurate and up-to-date information.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @cdellinger, 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?The documentation for a manual deploy for a db says this: "Any PostgreSQL database will do, as long as you provide the server with the correct DATABASE_URL env var and ensure that the database is accessible from the server.". I'm not seeing any mention of how to handle changes, does that mean as of right now, production schema changes need to be handled outside of wasp?
How
migrations work in general? You generate them for each database models change locally. You develop locally and your app works.
When it comes the time to deploy, the migrations folder is deployed as well. Wasp runs npx prisma migrate deploy in the server Docker container - which applies the migrations that are not yet applied to the production DB. This makes sure your production DB is in sync with the latest model changes you did in your app.
So, you don't really need to do anything special for the production setup for your DB, Wasp runs the migrations and stuff will just work 😄Yeah, so if you are using our Dockerfile, the result will be that schema migrations will be applied upon each server redeploy. As for data migrations, those are up to you manage.