Prisma schema to ER diagram

Paste schema.prisma and get an interactive ER diagram of the database that schema generates. That means 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, with one box per model and one line per relation field. That is useful right up until you have to reason about the database. You write a query by hand, review a migration, or 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 it _PostToTag, with columns A and B pointing at each side. No model in your code declares it.
Optional means nullable, and enums are types. DateTime? is a nullable column, and 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 diagram is drawn on a plain 2D canvas, 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. You still see what is beyond the limit.

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 and a generator block added to the schema. They usually also need 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. Model names become table names only when there is no @@map. Relation fields are not columns, so the diagram replaces them with 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.

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 diagram is free, and the dictionary is the paid part: $9 once.

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. That covers dumps, Prisma, DBML, Mermaid, PlantUML and 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: fourteen 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.