Studio with Prisma Next

Prisma Studio shows the migration history of your Prisma 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.

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.

Prerequisites

• Node.js installed
• A Prisma Next project on PostgreSQL

Create the project and provision a Prisma Postgres database in one step:

npm create prisma@next

To skip the prompts:

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 at src/prisma/contract.prisma, authored in PSL. 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

The scaffolded contract defines a User and a Post model. Compile it, plan a migration, and apply it:

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:

Applied 1 migration(s) (6 operation(s)) across 1 contract space(s)

--advance-ref db records where your database is by advancing a ref, so the next plan produces a delta instead of recreating everything.

Update the data model

Add an enum and two fields to 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

Compile the updated contract, plan, and apply:

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.

Seed the database

Migration history is easier to read next to real rows:

npm run db:seed

The CLI confirms with Seeded 3 users. The seed script writes through the Prisma Next ORM client; see Writing data for the API it uses.

Open Prisma Studio

A Prisma Next project has no schema.prisma, so pass the connection string with --url. Load it from .env first:

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.

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.

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

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 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.

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.

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 explains how those operations are planned and checked.

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 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

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 covers editing, filtering, and exporting.

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; the design story is in Rethinking Database Migrations.

Availability

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

• Prisma Next on PostgreSQL only. Prisma ORM projects using prisma migrate record history in a different format, and Studio does not support MongoDB, where Prisma Next stores its history differently.
• 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.