# Studio with Prisma ORM (/docs/studio/prisma-next)

> For the complete Prisma documentation index, see [llms.txt](https://www.prisma.io/docs/llms.txt). A markdown version of any docs page is available by appending `.md` to its URL.

Apply migrations to Prisma Postgres with Prisma ORM, then inspect the migration history, schema changes, executed SQL, and data in Prisma Studio.

Location: Studio > Studio with Prisma ORM

Prisma Studio shows the migration history of your [Prisma ORM](https://www.prisma.io/docs/orm) database as a visual timeline. Select any applied migration to see the models it changed, the SQL it executed, and a diff of the schema before and after.

This guide takes you from an empty directory to inspecting your own migration history. For browsing, editing, and filtering data in general, see [Getting Started](https://www.prisma.io/docs/studio/getting-started).

The Migrations view requires `@prisma/studio-core` 0.32.0 or later, which ships in the stable Prisma CLI since 7.9. Run Studio with `npx prisma@prev studio`. See the [Prisma ORM docs](https://www.prisma.io/docs/orm).

## Prerequisites [#prerequisites]

* [Node.js](https://nodejs.org) installed
* A Prisma ORM project on PostgreSQL

Create the project, and answer No to `Deploy to Prisma now?`:

  

#### bun

```bash
bun create prisma@latest
```

#### pnpm

```bash
pnpm create prisma@latest
```

#### yarn

```bash
yarn create prisma@latest
```

#### npm

```bash
npm create prisma@latest
```

To skip the prompts:

  

#### bun

```bash
bun create prisma@latest my-app --yes --provider postgres --authoring psl --template minimal
```

#### pnpm

```bash
pnpm create prisma@latest my-app --yes --provider postgres --authoring psl --template minimal
```

#### yarn

```bash
yarn create prisma@latest my-app --yes --provider postgres --authoring psl --template minimal
```

#### npm

```bash
npm create prisma@latest -- my-app --yes --provider postgres --authoring psl --template minimal
```

This scaffolds a [data model](https://www.prisma.io/docs/orm/data-modeling) at `src/prisma/contract.prisma`, authored in [PSL](https://www.prisma.io/docs/orm/contract-authoring/psl-syntax).

Next, create a [Prisma Postgres](https://www.prisma.io/docs/postgres) database and export its connection string. The generated scripts and the CLI read the environment variable, not `.env`:

  

#### bun

```bash
bunx create-db@latest
```

#### pnpm

```bash
pnpm dlx create-db@latest
```

#### yarn

```bash
yarn dlx create-db@latest
```

#### npm

```bash
npx create-db@latest
```

```bash
export DATABASE_URL="<the connection string create-db printed>"
```

The database expires after 24 hours unless you claim it; `create-db` prints a claim URL to keep it and attach it to your Prisma Console account.

## Apply the first migration [#apply-the-first-migration]

The scaffolded [contract](https://www.prisma.io/docs/orm/contract-authoring/the-data-contract) defines a `User` and a `Post` model. Compile it, [plan a migration](https://www.prisma.io/docs/orm/migrations/generating-a-migration), and [apply it](https://www.prisma.io/docs/orm/migrations/applying-a-migration):

  

#### bun

```bash
bunx prisma contract emit
bunx prisma migration plan --name init_users_posts
bunx prisma db migrate --advance-ref db
```

#### pnpm

```bash
pnpm prisma contract emit
pnpm prisma migration plan --name init_users_posts
pnpm prisma db migrate --advance-ref db
```

#### yarn

```bash
yarn prisma contract emit
yarn prisma migration plan --name init_users_posts
yarn prisma db migrate --advance-ref db
```

#### npm

```bash
npx prisma contract emit
npx prisma migration plan --name init_users_posts
npx prisma db migrate --advance-ref db
```

The CLI confirms the apply:

```text
Applied 6 operation(s) across 1 contract space
```

`--advance-ref db` records where your database is by advancing a [ref](https://www.prisma.io/docs/orm/migrations/the-migration-graph#name-important-states-with-refs), so the next plan produces a delta instead of recreating everything.

## Update the data model [#update-the-data-model]

Add an enum and two fields to `src/prisma/contract.prisma`:

```prisma title="src/prisma/contract.prisma"
enum Role {
  USER
  EDITOR
  ADMIN
}

model User {
  id        Int      @id @default(autoincrement())
  email     String   @unique
  username  String?
  name      String?
  bio       String?
  role      Role     @default(USER)
  posts     Post[]
  createdAt DateTime @default(now())
  updatedAt temporal.updatedAt()
}

model Post {
  id        Int      @id @default(autoincrement())
  title     String
  content   String?
  published Boolean  @default(false)
  author    User     @relation(fields: [authorId], references: [id])
  authorId  Int
  createdAt DateTime @default(now())
  updatedAt temporal.updatedAt()
}
```

## Create and apply another migration [#create-and-apply-another-migration]

Compile the updated contract, plan, and apply:

  

#### bun

```bash
bunx prisma contract emit
bunx prisma migration plan --name add_roles_and_publishing
bunx prisma db migrate --advance-ref db
```

#### pnpm

```bash
pnpm prisma contract emit
pnpm prisma migration plan --name add_roles_and_publishing
pnpm prisma db migrate --advance-ref db
```

#### yarn

```bash
yarn prisma contract emit
yarn prisma migration plan --name add_roles_and_publishing
yarn prisma db migrate --advance-ref db
```

#### npm

```bash
npx prisma contract emit
npx prisma migration plan --name add_roles_and_publishing
npx prisma db migrate --advance-ref db
```

Because the `db` ref was advanced in the previous step, the planner produces a delta: four `ALTER TABLE` operations that add the new columns and the enum's check constraint. To edit a planned migration before it runs, for example to add a backfill, see [Editing a migration](https://www.prisma.io/docs/orm/migrations/editing-a-migration).

> [!WARNING]
> Plans start from empty without a starting point
> 
> Without a `db` ref and without `--from`, `migration plan` compares against an empty database and recreates every table. If that happens, delete the planned migration directory and re-plan with `--from <previous-migration-dir>`, for example `--from 20260716T1155_init_users_posts`. See [The db ref](https://www.prisma.io/docs/orm/migrations/generating-a-migration#the-db-ref-skipping---from).

## Seed the database [#seed-the-database]

Migration history is easier to read next to real rows. The scaffold seeds sample users automatically the first time the app queries the database, so run the app once and hit its endpoint:

  

#### bun

```bash
bun run dev
```

#### pnpm

```bash
pnpm run dev
```

#### yarn

```bash
yarn dev
```

#### npm

```bash
npm run dev
```

Open the URL the command prints; the seeded users come back through the Prisma ORM client. Then stop the dev server. See [Writing data](https://www.prisma.io/docs/orm/fundamentals/writing-data) for the query API.

## Open Prisma Studio [#open-prisma-studio]

A Prisma ORM 8 project has no `schema.prisma`, so pass the [connection string](https://www.prisma.io/docs/postgres/database/connecting-to-your-database) with `--url`. Run Studio from a directory outside the project: the Prisma ORM 7 CLI that ships Studio cannot read the Prisma ORM 8 `prisma.config.ts` and fails if it finds one:

```bash
cd .. && npx prisma@prev studio --url "$DATABASE_URL"
```

Studio prints the local URL it serves on. Once the database has at least one applied migration, a **Migrations** item appears in the left navigation.

> [!NOTE]
> History lives in your database
> 
> Studio reads migration history from the connected database, not from your local `migrations/` directory. Migrations applied from CI or another machine appear automatically.

## Inspect migration history [#inspect-migration-history]

Open **Migrations**. The timeline lists every applied migration, newest first, with its name, apply time, operation count, and chips summarizing the change: `+1 model`, `~2 models`, `+3 fields`, `+1 enum`, `−1 field`. A ⚠️ marker flags migrations that contain a destructive change, so a dropped column is visible before you select anything. If a destructive migration needs undoing, see [Rollbacks and recovery](https://www.prisma.io/docs/orm/migrations/rollbacks-and-recovery).

![The Prisma Studio Migrations view showing a timeline of six applied migrations and a visual diff canvas of the selected migration.](https://www.prisma.io/img/studio/prisma-next-migrations/studio-migrations-timeline.png)

The selected migration is part of the URL, so you can link a teammate straight to it:

```
http://localhost:5555/#view=migrations&migration=3
```

## Review schema changes [#review-schema-changes]

Select a migration to see the schema as that migration changed it:

* **NEW** (green): a model the migration added.
* **UPDATED** (amber): a model whose table changed, with `+`, `−`, and `~` glyphs on the affected fields and `before → after` pills for changed types, nullability, or defaults.
* **UNCHANGED** (dimmed): neighboring models drawn for context.
* Enum cards, and [relation](https://www.prisma.io/docs/orm/fundamentals/relations-and-joins) edges between visible models.

Amber always means the migration changed that model's table. A model that only gained a back-relation, where the foreign key lives on the other table, stays dimmed, and the new relation edge is emphasized instead.

![The diff canvas for a migration that added a Category model and a relation, showing Category as NEW, Post as UPDATED, and User dimmed as UNCHANGED.](https://www.prisma.io/img/studio/prisma-next-migrations/studio-migrations-add-model-relation.png)

By default the view shows only the models the migration touched plus their direct neighbors. Toggle **All models** to see the entire schema as it stood at that point in history, including unchanged enums.

![The Migrations view with the All models toggle enabled, showing every model and enum in the schema at that migration.](https://www.prisma.io/img/studio/prisma-next-migrations/studio-migrations-all-models.png)

## Review executed SQL [#review-executed-sql]

Open the **SQL** panel to see the operations exactly as they ran, each labelled `additive` or `destructive`. This is the same SQL the migration runner executed; [How migrations work](https://www.prisma.io/docs/orm/migrations/how-migrations-work) explains how those operations are planned and checked.

![The SQL panel showing the ALTER TABLE statements and check constraint executed by a migration, each labelled with its operation class.](https://www.prisma.io/img/studio/prisma-next-migrations/studio-migrations-sql-panel.png)

## Compare schema versions [#compare-schema-versions]

Open the **Schema** panel to see a Prisma-schema diff between the migration's before and after state. Long unchanged runs collapse into folds you can click to expand.

![The Schema panel showing a color-coded diff of the Prisma schema before and after a migration, with collapsed unchanged sections.](https://www.prisma.io/img/studio/prisma-next-migrations/studio-migrations-schema-diff.png)

The diff is built for stable comparison and is not a copy of your source file. It uses a fixed field order and renders some attributes in expanded form, such as `@default(dbgenerated("autoincrement()"))`.

## Browse the resulting data [#browse-the-resulting-data]

Your tables are in the same Studio session under **Tables**. Move between what a migration changed and the rows it produced without leaving the app. [Getting Started](https://www.prisma.io/docs/studio/getting-started) covers editing, filtering, and exporting.

![The Prisma Studio table view showing rows in the post table, including the published column added by a migration.](https://www.prisma.io/img/studio/prisma-next-migrations/studio-post-table-data.png)

## How migration history works [#how-migration-history-works]

Prisma ORM records every apply in two tables in your database:

* `prisma_contract.ledger`: one row per applied migration, with its name, apply time, executed operations, and the schema versions it moved between.
* `prisma_contract.contract`: each schema version, stored once and keyed by hash.

Studio joins the two to build the timeline and the diffs. Because everything is read from the database, the history of any database you connect to is complete, including migrations you never ran yourself. These table names are also where to look if you inspect the history over SQL.

The hashes are the same ones that make Prisma ORM migrations [a graph rather than a numbered list](https://www.prisma.io/docs/orm/migrations/the-migration-graph); the design story is in [Rethinking Database Migrations](https://www.prisma.io/blog/rethinking-database-migrations).

## Availability [#availability]

| Surface                                                                                                                | Available                                                       |
| ---------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------- |
| Local Studio (`npx prisma@prev studio`)                                                                                | Yes, with `@prisma/studio-core` 0.32.0 or later                 |
| [Prisma Console](https://console.prisma.io/?utm_source=docs\&utm_medium=content\&utm_content=studio) (embedded Studio) | Yes, for databases with an applied Prisma ORM migration history |
| Prisma ORM projects using `prisma migrate`                                                                             | No                                                              |

In Prisma Console, open your database's Studio tab and select **Migrations**. The view is the same as local Studio, the selected migration is part of the Console URL, and no local setup is required.

The stable Prisma CLI bundles the Migrations view since 7.9 (`@prisma/studio-core` 0.33.0). Run `npx prisma@prev studio` from a directory outside your Prisma ORM 8 project; the Prisma ORM 7 CLI cannot read the Prisma ORM 8 `prisma.config.ts`.

## Limitations [#limitations]

* **Prisma ORM 8 on PostgreSQL only.** Prisma ORM 7 projects using `prisma migrate` record history in a different format, and [Studio does not support MongoDB](https://www.prisma.io/docs/studio), where Prisma ORM 8 [stores its history differently](https://www.prisma.io/docs/orm/migrations/the-migration-graph#database-specific-details).
* **Applied migrations only.** A planned but unapplied migration is not in the database, so it does not appear.
* **An empty history hides the view.** The **Migrations** item appears only after the first applied migration.
* **Older databases lose the diffs.** If the database was migrated by a Prisma ORM 8 version that predates schema snapshots, the timeline and SQL panel still work, and the diff canvas asks you to update Prisma ORM. Migrations applied after the update render normally.

## Related pages

- [`Getting Started`](https://www.prisma.io/docs/studio/getting-started): Learn how to set up and use Prisma Studio to manage your database