Think of it like this: You have a table with some users, none of which have a last name. Now you update schema.prisma with a required column called lastName, without a default value. How should Prisma handle the migration for you? Since Prisma can't guess the last name of every user, the only reasonable thing it can do is to ask you to recreate the data—which means resetting that table. To work around that, you need two migrations. You first set the column's default value to a placeholder—ensuring every row has a value. You then make a second migration where you remove the default value. This is, of course, just one of many reasons for why Prisma would want to reset a table, or sometimes even the whole database (if the effect is large enough). Prisma migrations are great, and they make life so much easier! But you still need to consider how they are applied and design your database accordingly: Prisma won't be able to magically solve the logical impossibilities that may occur otherwise. So, just like with everything else in programming, you need to be careful and considerate, and the more you practice; the easier it gets. I think Prisma sometimes overpromises on "making database design easy". It sure makes it easier, but you still need to think about what's going on behind the scenes. The way it abstracts the database design behind a neat little schema—together with its automatic migrations—can sometimes make you miss the forest for all the trees. Answer from die-maus on reddit.com