They serve two different environments. The prisma db push is not to be used in your production environment, as stated in the docs
db pushuses the same engine as Prisma Migrate to synchronize your Prisma schema with your database schema, and is best suited for schema prototyping. Thedb pushcommand:
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
prisma generate.If
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 changesNote:
db pushdoes not interact with or rely on migrations. The migrations table will not be updated, and no migration files will be generated.
The prisma migrate dev is used in you local environment, as explained in the docs
migrate devis a development command and should never be used in a production environment.This command:
- Replays the existing migration history in the shadow database in order to detect schema drift (edited or deleted migration file, or a manual changes to the database schema)
- Applies pending migrations to the shadow database (for example, new migrations created by colleagues)
- Generates a new migration from any changes you made to the Prisma schema before running
migrate dev- Applies all unapplied migrations to the development database and updates the
_prisma_migrationstable- Triggers the generation of artifacts (for example, the Prisma Client)
The
migrate devcommand will prompt you to reset the database in the following scenarios:
- Migration history conflicts caused by modified or missing migrations
- The database schema has drifted away from the end-state of the migration history
If you have any other question regarding this, there is this comparison in the docs explaining when to use one or the other.
Answer from Daniel Olavio Ferreira on Stack OverflowThey serve two different environments. The prisma db push is not to be used in your production environment, as stated in the docs
db pushuses the same engine as Prisma Migrate to synchronize your Prisma schema with your database schema, and is best suited for schema prototyping. Thedb pushcommand:
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
prisma generate.If
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 changesNote:
db pushdoes not interact with or rely on migrations. The migrations table will not be updated, and no migration files will be generated.
The prisma migrate dev is used in you local environment, as explained in the docs
migrate devis a development command and should never be used in a production environment.This command:
- Replays the existing migration history in the shadow database in order to detect schema drift (edited or deleted migration file, or a manual changes to the database schema)
- Applies pending migrations to the shadow database (for example, new migrations created by colleagues)
- Generates a new migration from any changes you made to the Prisma schema before running
migrate dev- Applies all unapplied migrations to the development database and updates the
_prisma_migrationstable- Triggers the generation of artifacts (for example, the Prisma Client)
The
migrate devcommand will prompt you to reset the database in the following scenarios:
- Migration history conflicts caused by modified or missing migrations
- The database schema has drifted away from the end-state of the migration history
If you have any other question regarding this, there is this comparison in the docs explaining when to use one or the other.
- Prisma db push syncs (and formats) your prisma schema to that of your database schema.
- While prisma migrate dev "command automatically generates SQL migration files (saved in /prisma/migrations) and applies them to the database".
The main difference between both is the generation of the migration files.
I ran `prisma db push`, and now when I run `prisma migrate dev` it prompts me to reset the database. How do I migrate without resetting and losing the data?
Correct pattern of Generating Migrations
How do I use Prisma without having to wipe my database all the time?
What's difference between prisma db push and prisma db migrate
I'm using Prisma for a large project I've been working on for the past few months, and I still don't understand the flow of it. At first I was migrating every time I made a change to my schema, and constantly getting the "All data will be lost" prompt. Since then I've learned to use `db push` while developing and then migrate when a feature is finished, but it's still constantly making me reset my database.
Right now I'm using the same db for dev and staging (because I don't want to pay for 2 different ones) but I'd imagine this would still be an issue if I had separate databases. What do I need to do to stop being forced to reset my db? Or, at least, how would I migrate my development db to mirror my production db without it being wiped?
As you can probably tell, this is my first time working with Prisma (or any ORM, in depth) so this might be a stupid question, but I can't find much online besides general tutorials. Any help would be greatly appreciated!
I'm working on a little project with supabase and prisma, I've just been using one dev database which I update with prisma migrate dev. For production migrations, you're supposed to use prisma migrate deploy, which the prisma docs say to put in a CI/CD pipeline.
-
I don't have a CI/CD pipeline
-
I can't run it locally from my project directory, cause prisma uses the
DATABASE_URLenvironment, which is pointing to my dev database
So I'm wondering where y'all would actually run prisma migrate deploy from? Should I just bite the bullet and learn some github actions? Or is there an easier way?
EDIT: The prisma docs recommend using dotenv-cli to use switch between .env files, but I'm kinda worried that I might fuck up somehow and end up running prisma migrate reset on my prod database, and delete everything. But, seems like that might be my plan until I figure out some CI/CD stuff.
Still definitely open to any advice though!