# Prototyping your schema (/docs/orm/prisma-migrate/workflows/prototyping-your-schema)

Location: ORM > Prisma Migrate > Workflows > Prototyping your schema

The Prisma CLI has a dedicated command for prototyping schemas: [`db push`](/orm/reference/prisma-cli-reference#db-push)

`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.
* Does not automatically trigger generators (for example, Prisma Client). You need to manually invoke `prisma generate` after making schema changes.
* If `db push` anticipates that the changes could result in data loss, it will:
  * Throw an error
  * Require the `--accept-data-loss` option if you still want to make the changes

> [!NOTE]
> Notes
> 
> * `db push` does not interact with or rely on migrations. The migrations table `_prisma_migrations` will not be created or updated, and no migration files will be generated.
> * When working with PlanetScale, we recommend that you use `db push` instead of `migrate`. For details refer to our Getting started documentation, either [Start from scratch guide](/prisma-orm/quickstart/planetscale) or [Add to existing project guide](/prisma-orm/add-to-existing-project/planetscale) depending on your situation.

Choosing db push or Prisma Migrate [#choosing-db-push-or-prisma-migrate]

`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 `db push`)
* You do not need to control how schema changes impact data. There is no way to orchestrate schema and data migrations—if `db push` anticipates that changes will result in data loss, you can either accept data loss with the `--accept-data-loss` option or stop the process. There is no way to customize the changes.

See [Schema prototyping with `db push`](/orm/prisma-migrate/workflows/prototyping-your-schema) 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 push` for 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](/orm/prisma-migrate/workflows/customizing-migrations#example-rename-a-field).
* You want to keep track of changes made to the database schema over time. `db push` does 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 push` again to revert to the original state, but this might result in data loss.

Can I use Prisma Migrate and db push together? [#can-i-use-prisma-migrate-and-db-push-together]

Yes, you can [use `db push` and Prisma Migrate together in your development workflow](/orm/prisma-migrate/workflows/prototyping-your-schema) . For example, you can:

* Use `db push` to prototype a schema at the start of a project and initialize a migration history when you are happy with the first draft
* Use `db push` to prototype a change to an existing schema, then run `prisma migrate dev` to generate a migration from your changes (you will be asked to reset)

Prototyping a new schema [#prototyping-a-new-schema]

The following scenario demonstrates how to use `db push` to synchronize a new schema with an empty database, and evolve that schema - including what happens when `db push` detects that a change will result in data loss.

* Create a first draft of your schema:

  ```prisma title="schema.prisma"
  generator client {
    provider = "prisma-client"
    output   = "./generated"
  }

  datasource db {
    provider = "postgresql"
  }

  model User {
    id       Int      @id @default(autoincrement())
    name     String
    jobTitle String
    posts    Post[]
    profile  Profile?
  }

  model Profile {
    id       Int    @id @default(autoincrement())
    biograpy String // Intentional typo!
    userId   Int    @unique
    user     User   @relation(fields: [userId], references: [id])
  }

  model Post {
    id         Int        @id @default(autoincrement())
    title      String
    published  Boolean    @default(true)
    content    String     @db.VarChar(500)
    authorId   Int
    author     User       @relation(fields: [authorId], references: [id])
    categories Category[]
  }

  model Category {
    id    Int    @id @default(autoincrement())
    name  String @db.VarChar(50)
    posts Post[]

    @@unique([name])
  }
  ```

* Use `db push` to push the initial schema to the database:

  
    

#### npm

```bash
npx prisma db push
```

#### pnpm

```bash
pnpm dlx prisma db push
```

#### yarn

```bash
yarn dlx prisma db push
```

#### bun

```bash
bunx --bun prisma db push
```
  

* Create some example content:

  ```ts title="main.ts"
  const add = await prisma.user.create({
    data: {
      name: "Eloise",
      jobTitle: "Programmer",
      posts: {
        create: {
          title: "How to create a MySQL database",
          content: "Some content",
        },
      },
    },
  });
  ```

* Make an additive change - for example, create a new required field:

  ```prisma highlight=6;add title="schema.prisma"
  model Post {
    id          Int        @id @default(autoincrement())
    title       String
    description String // [!code ++]
    published   Boolean    @default(true)
    content     String     @db.VarChar(500)
    authorId    Int
    author      User       @relation(fields: [authorId], references: [id])
    categories  Category[]
  }
  ```

* Push the changes:

  
    

#### npm

```bash
npx prisma db push
```

#### pnpm

```bash
pnpm dlx prisma db push
```

#### yarn

```bash
yarn dlx prisma db push
```

#### bun

```bash
bunx --bun prisma db push
```
  

  `db push` will fail because you cannot add a required field to a table with existing content unless you provide a default value.

* Reset **all data** in your database and re-apply migrations.

  
    

#### npm

```bash
npx prisma migrate reset
```

#### pnpm

```bash
pnpm dlx prisma migrate reset
```

#### yarn

```bash
yarn dlx prisma migrate reset
```

#### bun

```bash
bunx --bun prisma migrate reset
```
  

> [!NOTE]
> Note
> 
> Unlike Prisma Migrate, `db push` does not generate migrations that you can modify to preserve data, and is therefore best suited for prototyping in a development environment.

* Continue to evolve your schema until it reaches a relatively stable state.

* Initialize a migration history:

  
    

#### npm

```bash
npx prisma migrate dev --name initial-state
```

#### pnpm

```bash
pnpm dlx prisma migrate dev --name initial-state
```

#### yarn

```bash
yarn dlx prisma migrate dev --name initial-state
```

#### bun

```bash
bunx --bun prisma migrate dev --name initial-state
```
  

  The steps taken to reach the initial prototype are not preserved - `db push` does not generate a history.

* Push your migration history and Prisma schema to source control (e.g. Git).

At this point, the final draft of your prototyping is preserved in a migration and can be pushed to other environments (testing, production, or other members of your team).

Prototyping with an existing migration history [#prototyping-with-an-existing-migration-history]

The following scenario demonstrates how to use `db push` to prototype a change to a Prisma schema where a migration history already exists.

* Check out the latest Prisma schema and migration history:

  ```prisma title="schema.prisma"
  generator client {
    provider = "prisma-client"
    output   = "./generated"
  }

  datasource db {
    provider = "postgresql"
  }

  model User {
    id       Int      @id @default(autoincrement())
    name     String
    jobTitle String
    posts    Post[]
    profile  Profile?
  }

  model Profile {
    id       Int    @id @default(autoincrement())
    biograpy String // Intentional typo!
    userId   Int    @unique
    user     User   @relation(fields: [userId], references: [id])
  }

  model Post {
    id         Int        @id @default(autoincrement())
    title      String
    published  Boolean    @default(true)
    content    String     @db.VarChar(500)
    authorId   Int
    author     User       @relation(fields: [authorId], references: [id])
    categories Category[]
  }

  model Category {
    id    Int    @id @default(autoincrement())
    name  String @db.VarChar(50)
    posts Post[]

    @@unique([name])
  }
  ```

* Prototype your new feature, which can involve any number of steps. For example, you might:

  * Create a `tags String[]` field, then run `db push`
  * Change the field type to `tags Tag[]` and add a new model named `Tag`, then run `db push`
  * Change your mind and restore the original `tags String[]` field, then call `db push`
  * Make a manual change to the `tags` field in the database - for example, adding a constraint

  After experimenting with several solutions, the final schema change looks like this:

  ```prisma title="schema.prisma"
  model Post {
    id          Int        @id @default(autoincrement())
    title       String
    description String
    published   Boolean    @default(true)
    content     String     @db.VarChar(500)
    authorId    Int
    author      User       @relation(fields: [authorId], references: [id])
    categories  Category[]
    tags        String[]
  }
  ```

* To create a migration that adds the new `tags` field, run the `migrate dev` command:

  
    

#### npm

```bash
npx prisma migrate dev --name added-tags
```

#### pnpm

```bash
pnpm dlx prisma migrate dev --name added-tags
```

#### yarn

```bash
yarn dlx prisma migrate dev --name added-tags
```

#### bun

```bash
bunx --bun prisma migrate dev --name added-tags
```
  

  Prisma Migrate will prompt you to reset because the changes you made manually and with `db push` while prototyping are not part of the migration history:

  ```bash
  √ Drift detected: Your database schema is not in sync with your migration history.

  We need to reset the PostgreSQL database "prototyping" at "localhost:5432".
  ```

> [!WARNING]
> This will result in total data loss.

  

#### npm

```bash
npx prisma migrate reset
```

#### pnpm

```bash
pnpm dlx prisma migrate reset
```

#### yarn

```bash
yarn dlx prisma migrate reset
```

#### bun

```bash
bunx --bun prisma migrate reset
```

* Prisma Migrate replays the existing migration history, generates a new migration based on your schema changes, and applies those changes to the database.

> [!NOTE]
> When using `migrate dev`, if your schema changes mean that seed scripts will no longer work, you can use the `--skip-seed` flag to ignore seed scripts.

At this point, the final result of your prototyping is preserved in a migration, and can be pushed to other environments (testing, production, or other members of your team).

## Related pages

- [`Baselining a database`](https://www.prisma.io/docs/orm/prisma-migrate/workflows/baselining): How to initialize a migration history for an existing database that contains important data.
- [`Customizing migrations`](https://www.prisma.io/docs/orm/prisma-migrate/workflows/customizing-migrations): How to edit a migration file before applying it to avoid data loss in production.
- [`Development and production`](https://www.prisma.io/docs/orm/prisma-migrate/workflows/development-and-production): How to use Prisma Migrate commands in development and production environments
- [`Generating down migrations`](https://www.prisma.io/docs/orm/prisma-migrate/workflows/generating-down-migrations): How to generate a down migration SQL file that reverses a given migration file
- [`Native database functions`](https://www.prisma.io/docs/orm/prisma-migrate/workflows/native-database-functions): How to enable PostgreSQL native database functions for projects that use Prisma Migrate.