Prisma schema to ER diagram

Paste schema.prisma and get an interactive ER diagram of the database that schema generates — mapped table names, the scalar foreign key columns behind your relation fields, and the join tables an implicit many-to-many creates. Nothing to install, no signup; the schema is parsed in your browser and never uploaded.

Your schema

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

generator client {
  provider = "prisma-client-js"
}

enum Role {
  READER
  AUTHOR
  EDITOR
}

/// People who can sign in
model User {
  id        Int       @id @default(autoincrement())
  email     String    @unique @db.VarChar(160)
  name      String?
  role      Role      @default(READER)
  createdAt DateTime  @default(now()) @map("created_at")
  posts     Post[]
  comments  Comment[]

  @@map("users")
}

/// Articles; a draft is a post with published = false
model Post {
  id          Int       @id @default(autoincrement())
  slug        String    @unique @db.VarChar(200)
  title       String    @db.VarChar(200)
  body        String
  published   Boolean   @default(false)
  publishedAt DateTime? @map("published_at")
  authorId    Int       @map("author_id")
  author      User      @relation(fields: [authorId], references: [id])
  tags        Tag[]
  comments    Comment[]

  @@index([authorId])
  @@map("posts")
}

model Tag {
  id    Int    @id @default(autoincrement())
  name  String @unique @db.VarChar(60)
  posts Post[]

  @@map("tags")
}

model Comment {
  id       Int      @id @default(autoincrement())
  body     String
  created  DateTime @default(now())
  postId   Int      @map("post_id")
  post     Post     @relation(fields: [postId], references: [id], onDelete: Cascade)
  authorId Int      @map("author_id")
  author   User     @relation(fields: [authorId], references: [id])

  @@map("comments")
}

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

generator client {
  provider = "prisma-client-js"
}

enum Role {
  READER
  AUTHOR
  EDITOR
}

/// People who can sign in
model User {
  id        Int       @id @default(autoincrement())
  email     String    @unique @db.VarChar(160)
  name      String?
  role      Role      @default(READER)
  createdAt DateTime  @default(now()) @map("created_at")
  posts     Post[]
  comments  Comment[]

  @@map("users")
}

/// Articles; a draft is a post with published = false
model Post {
  id          Int       @id @default(autoincrement())
  slug        String    @unique @db.VarChar(200)
  title       String    @db.VarChar(200)
  body        String
  published   Boolean   @default(false)
  publishedAt DateTime? @map("published_at")
  authorId    Int       @map("author_id")
  author      User      @relation(fields: [authorId], references: [id])
  tags        Tag[]
  comments    Comment[]

  @@index([authorId])
  @@map("posts")
}

model Tag {
  id    Int    @id @default(autoincrement())
  name  String @unique @db.VarChar(60)
  posts Post[]

  @@map("tags")
}

model Comment {
  id       Int      @id @default(autoincrement())
  body     String
  created  DateTime @default(now())
  postId   Int      @map("post_id")
  post     Post     @relation(fields: [postId], references: [id], onDelete: Cascade)
  authorId Int      @map("author_id")
  author   User     @relation(fields: [authorId], references: [id])

  @@map("comments")
}

Your diagram appears here.

Four models above, five tables below — the fifth is the one Prisma writes for Post ↔ Tag. Replace the example with your own schema.

A Prisma schema is not the same shape as its database

ErdDocs draws the database the schema produces, not the file it is written in. Most tools that draw a Prisma schema draw the file — one box per model, one line per relation field — which is useful right up until you have to reason about the database: write a query by hand, review a migration, explain the design to someone who only ever sees tables. Prisma rewrites four things on the way in, and the diagram above shows the result of all four:

Names. @@map("users") and @map("author_id") are what the database ends up called. The model name is a TypeScript convenience; the table name is what you type in psql.
Relation fields are not columns. A field like author User @relation(...) does not exist in the database at all — the column is author_id, declared separately. The diagram drops the former and draws the latter, with the foreign key between them.
Implicit many-to-many becomes a real table. tags Tag[] on one side and posts Post[] on the other produce a join table Prisma names _PostToTag, with columns A and B pointing at each side. It is invisible in your code and very visible in your database.
Optional means nullable, and enums are types. DateTime? is a nullable column; enum Role is a type the migration creates. Both show up where a reviewer expects them.

Three steps, none of them an install

01Open prisma/schema.prisma in your editor and copy it whole — datasource block and all; that block is read and ignored.
02Paste it into the panel above. The format is detected from what you paste, so there is no menu to find first.
03Export what you came for: PNG or SVG for a document, Mermaid or DBML to keep the diagram in the repository, or switch to the dictionary and print a PDF.

When the schema is large

Real Prisma projects are not four models. The parser was built against cal.com, whose schema produces 105 tables, and reads it without errors. The canvas is a plain 2D canvas rather than a pile of DOM nodes, so a schema of that size pans and zooms at the frame rate of your screen; the free tier draws 25 tables and parses the rest, showing what is beyond the limit rather than pretending it does not exist.

FAQ

Do I need to install anything or run prisma generate?

No. Paste the schema.prisma file exactly as it sits in your repository and ErdDocs draws the diagram. Generator-based tools (prisma-erd-generator and friends) need the Prisma CLI in the project, a generator block added to the schema, and usually Puppeteer or mermaid-cli to turn the result into a picture; ErdDocs needs a browser tab and the text you already have.

Does the diagram show what Prisma actually creates in the database?

Yes, and that is the point. Model names become table names only when there is no @@map; relation fields are not columns, so they are replaced by the scalar foreign key columns Prisma really writes; an implicit many-to-many relation gets the join table Prisma creates for it, named _ModelAToModelB with its A and B columns. What you see is the schema your migration produces, not a redrawing of the file.

What happens to @map and @@map names?

They win, because the database uses them. A model mapped with @@map("blog_posts") is drawn as blog_posts, and a field mapped with @map("author_id") is drawn as author_id. The Prisma names stay in your code; the diagram is about the database, so it uses the database names.

Can I get documentation out of it, not just a picture?

Switch to the Data Dictionary view and the same schema becomes a printable document: every table, column, type, nullability, default, index and relation. Prisma /// documentation comments become the Description column, so a schema that is already commented documents itself. The dictionary is the paid part — $9 once — and the diagram is free.

Is my schema uploaded anywhere?

No. The parser is JavaScript running in your browser, so the schema is read on your own machine and never sent to a server. There is no account, and closing the tab is all the cleanup there is.

SQL to ER diagram — the same tool with every input it reads: dumps, Prisma, DBML, Mermaid, PlantUML, ORM models.
Prisma schema to SQL — the same schema as CREATE TABLE statements.
DBML to ER diagram — for schemas that live in dbdiagram.io syntax.
SQL to PlantUML — when the diagram has to end up in a UML toolchain.
Data dictionary generator — the printable document behind the diagram.
Example schemas — eleven domains with the SQL to paste, each teaching one modeling pattern.
Agent Link API — put a live diagram of any schema in a README or an AI answer.