Prisma to PlantUML

Paste schema.prisma and copy PlantUML — entities with their keys, nullability and crow’s foot relations, ready for a .puml file. No CLI, no generator block, nothing uploaded.

Your schema

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

enum InvoiceState {
  DRAFT
  SENT
  PAID
  VOID
}

model Account {
  id            Int            @id @default(autoincrement())
  company       String         @db.VarChar(160)
  billingEmail  String         @unique @map("billing_email") @db.VarChar(160)
  vatNumber     String?        @map("vat_number") @db.VarChar(20)
  subscriptions Subscription[]
  invoices      Invoice[]

  @@map("accounts")
}

model Plan {
  id            Int            @id @default(autoincrement())
  code          String         @unique @db.VarChar(20)
  name          String         @db.VarChar(80)
  monthlyPrice  Decimal        @map("monthly_price") @db.Decimal(10, 2)
  seatsIncluded Int            @map("seats_included")
  subscriptions Subscription[]

  @@map("plans")
}

model Subscription {
  id         Int       @id @default(autoincrement())
  accountId  Int       @map("account_id")
  account    Account   @relation(fields: [accountId], references: [id])
  planId     Int       @map("plan_id")
  plan       Plan      @relation(fields: [planId], references: [id])
  startedOn  DateTime  @map("started_on")
  cancelledOn DateTime? @map("cancelled_on")
  seats      Int       @default(1)

  @@index([accountId])
  @@map("subscriptions")
}

model Invoice {
  id        Int          @id @default(autoincrement())
  accountId Int          @map("account_id")
  account   Account      @relation(fields: [accountId], references: [id])
  number    String       @unique @db.VarChar(20)
  state     InvoiceState @default(DRAFT)
  total     Decimal      @db.Decimal(12, 2)
  issuedOn  DateTime     @map("issued_on")
  paidOn    DateTime?    @map("paid_on")
  payments  Payment[]

  @@map("invoices")
}

model Payment {
  id        Int      @id @default(autoincrement())
  invoiceId Int      @map("invoice_id")
  invoice   Invoice  @relation(fields: [invoiceId], references: [id], onDelete: Cascade)
  amount    Decimal  @db.Decimal(12, 2)
  reference String   @db.VarChar(60)
  receivedAt DateTime @map("received_at")

  @@map("payments")
}

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

enum InvoiceState {
  DRAFT
  SENT
  PAID
  VOID
}

model Account {
  id            Int            @id @default(autoincrement())
  company       String         @db.VarChar(160)
  billingEmail  String         @unique @map("billing_email") @db.VarChar(160)
  vatNumber     String?        @map("vat_number") @db.VarChar(20)
  subscriptions Subscription[]
  invoices      Invoice[]

  @@map("accounts")
}

model Plan {
  id            Int            @id @default(autoincrement())
  code          String         @unique @db.VarChar(20)
  name          String         @db.VarChar(80)
  monthlyPrice  Decimal        @map("monthly_price") @db.Decimal(10, 2)
  seatsIncluded Int            @map("seats_included")
  subscriptions Subscription[]

  @@map("plans")
}

model Subscription {
  id         Int       @id @default(autoincrement())
  accountId  Int       @map("account_id")
  account    Account   @relation(fields: [accountId], references: [id])
  planId     Int       @map("plan_id")
  plan       Plan      @relation(fields: [planId], references: [id])
  startedOn  DateTime  @map("started_on")
  cancelledOn DateTime? @map("cancelled_on")
  seats      Int       @default(1)

  @@index([accountId])
  @@map("subscriptions")
}

model Invoice {
  id        Int          @id @default(autoincrement())
  accountId Int          @map("account_id")
  account   Account      @relation(fields: [accountId], references: [id])
  number    String       @unique @db.VarChar(20)
  state     InvoiceState @default(DRAFT)
  total     Decimal      @db.Decimal(12, 2)
  issuedOn  DateTime     @map("issued_on")
  paidOn    DateTime?    @map("paid_on")
  payments  Payment[]

  @@map("invoices")
}

model Payment {
  id        Int      @id @default(autoincrement())
  invoiceId Int      @map("invoice_id")
  invoice   Invoice  @relation(fields: [invoiceId], references: [id], onDelete: Cascade)
  amount    Decimal  @db.Decimal(12, 2)
  reference String   @db.VarChar(60)
  receivedAt DateTime @map("received_at")

  @@map("payments")
}

Your diagram appears here.

Replace the example with your schema, then Export → PlantUML.

What comes out

The real export of the schema above, trimmed to one entity and the relations around it. Note cancelled_on without an asterisk — PlantUML’s own way of saying a column is optional:

@startuml
' Generated with erddocs.com — paste SQL, get an ER diagram and a data dictionary
hide circle
skinparam linetype ortho

entity "subscriptions" as subscriptions {
  *id : Int <<PK>>
  --
  *account_id : Int <<FK>>
  *plan_id : Int <<FK>>
  *started_on : DateTime
  cancelled_on : DateTime
  *seats : Int
}

subscriptions }o--|| accounts : account_id
subscriptions }o--|| plans : plan_id

A package, or a paste

ErdDocs converts what you paste, with nothing installed and nothing added to the project. The existing answers are packages you install: prisma-uml as a CLI, prisma-generator-plantuml-erd as a generator block followed by prisma generate, a VS Code extension for the same job — and inside a project that regenerates diagrams on every schema change, that is the right shape and it is worth the install.

The awkward cases are the ones where the schema is not yours to modify — a file in a review, an attachment, a repository you are still deciding about — or where adding a dependency to answer one question costs more than the answer is worth. ErdDocs covers those: the file goes into a browser tab, and the schema stays on your machine while you read it.

The database, not the file

A Prisma schema is not shaped like the database it produces, and the export follows the database: @@map and @map names win, relation fields give way to the scalar foreign key columns Prisma actually writes, optional fields become nullable columns without an asterisk, and an implicit many-to-many arrives as the join table it really creates. That is the difference between a diagram you can hand to someone writing SQL and a redrawing of the file they could have read themselves.

FAQ

Is this the PRISMA flow diagram for systematic reviews?

No — different PRISMA entirely. ErdDocs works on Prisma the ORM: it turns the schema.prisma file that describes a database into a PlantUML ER diagram. The PRISMA 2020 flow diagram used in systematic reviews is an unrelated standard, and a paper needs a different tool for it.

How is this different from prisma-uml?

prisma-uml and prisma-generator-plantuml-erd are packages you install: one as a CLI, the other as a generator block in schema.prisma followed by prisma generate. They fit a build that produces diagrams on every change. This is the other case — a schema you were sent, a file in a pull request, a laptop where installing a toolchain to read one file is not worth it. Paste it and copy the PlantUML.

What does the generated PlantUML contain?

One entity per table, primary keys first and separated by a rule, then the rest. Keys carry <<PK>>, <<FK>> and <<UK>> markers, mandatory columns carry PlantUML’s asterisk, and types keep the size and precision the schema gives them. Relations are crow’s foot lines labeled with the foreign key column, enums become enum blocks, and the header sets hide circle and orthogonal routing so it reads as an ER diagram rather than a class diagram.

Does it show the tables Prisma creates rather than the models I wrote?

Yes. @@map and @map names win because the database uses them, relation fields are replaced by the scalar foreign key columns behind them, and an implicit many-to-many appears as the join table Prisma really creates. The diagram is of the database, not of the file.

Is it free?

Copying PlantUML is free at any schema size, with no account — the 25-table limit is on what gets drawn, not on what gets converted. The text carries one comment line naming ErdDocs; $9 once removes it and lifts the limit.

Prisma to DBML — the same schema for dbdiagram and dbdocs.
SQL to PlantUML — starting from a dump instead.
Prisma schema to ER diagram — the interactive version of the same picture.
Prisma schema to SQL — CREATE TABLE statements from the same file.
Example schemas — eleven domains to paste and convert.
SQL to ER diagram — the tool with every format it reads and writes.