Migrating database without resetting data
wasp db migrate-dev works when updating the schema but it deleted all data. How can I preserve data while making changes to tables?
5 Replies
Hi @Juan. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
When you run wasp db migrate-dev, it should not delete all your data by default. The command is designed to synchronize your development database with your current schema by generating and applying migrations, not by resetting or dropping data. Data loss typically only occurs if you explicitly run wasp db reset, which drops all tables and data before reapplying migrations, or if your migration itself includes destructive changes (like dropping tables or columns) that result in data loss Database Commands.
If you want to preserve your data while making schema changes, follow these guidelines:
- Use wasp db migrate-dev for schema changes. This command applies migrations incrementally and should not delete your data unless the migration itself is destructive.
- Avoid using wasp db reset unless you intentionally want to clear all data and start fresh.
- If your schema change requires adding new fields to existing tables, consider providing default values or making the fields nullable to avoid migration errors.
- For more complex data migrations (e.g., populating new fields for existing records), you can write custom scripts using the Prisma client to update your data after the migration. There is an open discussion about best practices for data migrations in Wasp, and currently, you may need to write such scripts manually Support data migrations & provide best practices and examples.
If you are experiencing data loss when running wasp db migrate-dev, double-check your migration steps and the generated migration files to ensure they do not contain destructive operations.
In summary: Use wasp db migrate-dev for non-destructive schema changes to preserve your data. Only use wasp db reset if you want to wipe your database. For data migrations, write custom scripts as needed.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @Juan, 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?
Hm yeah taht should not delete data. It basicalyly runs prisma in behind, so there isn't any way really for us to accidentally delete data.
It will delete some column potentially if your migration deletes a column.
Do you have omre details on the situation, what exactly happened?
I just added one column to a table and when I ran the migrate command it warned me that all data was going to be deleted. I'm still testing so didn't matter just want to make sure I don't run into this in prod.
Hm if you added one column, then in theory, no data should be deleted. Is it possible you also changed a type of one of the existing columns, or deleted some existing column? If so, that would explain why deletion will happen (and it has to, no other way about it).
Btw when you are doing such changes to your database, there is a way to do it, called "expand and contract" -> https://www.prisma.io/dataguide/types/relational/expand-and-contract-pattern (prisma docs on it).
In essence it is simple, you add new column instead of modfiying/deleting old ones, you push that schema to prduction, then you do data migration (e.g. copy data from old column to new one) + start using new data, and then you can delete old data and apply another schema change that removes old columns.
Of course if you are still just in deevlopment and there is no produciton db, then it is easier to just drop the data and go from start.
Prisma's Data Guide
Using the expand and contract pattern | Prisma's Data Guide
In this article, we introduce the expand and contract pattern to help migrate data and clients to a new schema.
This is great to have. Thank you