The Prisma CLI has a dedicated command for prototyping schemas:
db push uses the same engine as Prisma Migrate to synchronize your Prisma schema with your database schema. The
db push command:
Introspects the database to infer and executes the changes required to make your database schema reflect the state of your Prisma schema.
By default, after changes have been applied to the database schema, generators are triggered (for example, Prisma Client). You do not need to manually invoke
db pushanticipates that the changes could result in data loss, it will:
- Throw an error
- Require the
--accept-data-lossoption if you still want to make the changes
db pushdoes not interact with or rely on migrations. The migrations table will not be updated, and no migration files will be generated.
- When working with PlanetScale, we recommend that you use
db pushinstead of
migrate. For details refer to our Getting Started documentation, either Start from scratch or Add to existing project depending on your situation.
db push works well if:
- You want to quickly prototype and iterate on schema design locally without the need to deploy these changes to other environments such as other developers, or staging and production environments.
- You are prioritizing reaching a desired end-state and not the changes or steps executed to reach that end-state (there is no way to preview changes made by
- You do not need to control how schema changes impact data. There is no way to orchestrate schema and data migrations—if
db pushanticipates that changes will result in data loss, you can either accept data loss with the
--accept-data-lossoption or stop the process. There is no way to customize the changes.
See Schema prototyping with
db push for an example of how to use
db push in this way.
db push is not recommended if:
- You want to replicate your schema changes in other environments without losing data. You can use
db pushfor prototyping, but you should use migrations to commit the schema changes and apply these in your other environments.
- You want fine-grained control over how the schema changes are executed - for example, renaming a column instead of dropping it and creating a new one.
- You want to keep track of changes made to the database schema over time.
db pushdoes not create any artifacts that allow you to keep track of these changes.
- You want the schema changes to be reversible. You can use
db pushagain to revert to the original state, but this might result in data loss.
Yes, you can use
db push and Prisma Migrate together in your development workflow . For example, you can:
db pushto prototype a schema at the start of a project and initialize a migration history when you are happy with the first draft
db pushto prototype a change to an existing schema, then run
prisma migrate devto generate a migration from your changes (you will be asked to reset)