# Studio with Prisma Next (/docs/studio/prisma-next) Location: Studio > Studio with Prisma Next Prisma Studio shows the migration history of your [Prisma Next](/orm/next) 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](/studio/getting-started). The Migrations view requires `@prisma/studio-core` 0.32.0 or later, currently available in the Prisma CLI's `dev` release: run Studio with `npx prisma@dev studio`. Prisma Next is in [early access](/orm/next). Prerequisites [#prerequisites] * [Node.js](https://nodejs.org) installed * A Prisma Next project on PostgreSQL Create the project and provision a [Prisma Postgres](/postgres) database in one step: ```bash npm create prisma@next ``` To skip the prompts: ```bash npm create prisma@next -- my-app --yes --provider postgres --authoring psl \ --template minimal --prisma-postgres --install --emit ``` This writes your `DATABASE_URL` into `.env` and scaffolds a [data model](/orm/next/data-modeling) at `src/prisma/contract.prisma`, authored in [PSL](/orm/next/contract-authoring/psl-syntax). The database expires after 24 hours unless you claim it; open the `CLAIM_URL` in `.env` to keep it and attach it to your Prisma Console account. Apply the first migration [#apply-the-first-migration] The scaffolded [contract](/orm/next/contract-authoring/the-data-contract) defines a `User` and a `Post` model. Compile it, [plan a migration](/orm/next/migrations/generating-a-migration), and [apply it](/orm/next/migrations/applying-a-migration): ```bash npx prisma-next contract emit npx prisma-next migration plan --name init_users_posts npx prisma-next migrate --advance-ref db ``` The CLI confirms the apply: ```text Applied 1 migration(s) (6 operation(s)) across 1 contract space(s) ``` `--advance-ref db` records where your database is by advancing a [ref](/orm/next/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: ```bash npx prisma-next contract emit npx prisma-next migration plan --name add_roles_and_publishing npx prisma-next 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](/orm/next/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 `, for example `--from 20260716T1155_init_users_posts`. See [The db ref](/orm/next/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: ```bash npm run db:seed ``` The CLI confirms with `Seeded 3 users.` The seed script writes through the Prisma Next ORM client; see [Writing data](/orm/next/fundamentals/writing-data) for the API it uses. > [!NOTE] > Namespaced ORM access > > `db.orm` is keyed by namespace first: reach models as `db.orm.public.User`, not `db.orm.User`. If the scaffolded `seed.ts` uses the shorter form, it fails with `TypeError: Cannot read properties of undefined (reading 'where')`. Add the namespace to fix it. Open Prisma Studio [#open-prisma-studio] A Prisma Next project has no `schema.prisma`, so pass the [connection string](/postgres/database/connecting-to-your-database) with `--url`. Load it from `.env` first: ```bash set -a && . ./.env && set +a npx prisma@dev studio --url "$DATABASE_URL" ``` Studio opens at `http://localhost:5555`. 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](/orm/next/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. 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](/orm/next/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. 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. 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](/orm/next/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. 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. The diff is a projection built for stable comparison, 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](/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. How migration history works [#how-migration-history-works] Prisma Next 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. Nothing is read from disk and nothing is reconstructed, which is why 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 Next migrations [a graph rather than a numbered list](/orm/next/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@dev 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 Next 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 (`prisma@latest`) currently bundles an older Studio without the Migrations view. Use `npx prisma@dev studio` until it lands in a stable release. Limitations [#limitations] * **Prisma Next on PostgreSQL only.** Prisma ORM projects using `prisma migrate` record history in a different format, and [Studio does not support MongoDB](/studio), where Prisma Next [stores its history differently](/orm/next/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 Next version that predates schema snapshots, the timeline and SQL panel still work, and the diff canvas asks you to update Prisma Next. 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