Prisma to DBML

Paste schema.prisma and copy DBML — ready for dbdiagram or dbdocs, with the diagram drawn beside it so you can see the conversion before you trust it. No generator to install, no prisma generate, nothing uploaded.

Your schema

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

enum ListingState {
  DRAFT
  LIVE
  UNDER_OFFER
  SOLD
}

/// Estate agencies we work with
model Agency {
  id      Int     @id @default(autoincrement())
  name    String  @db.VarChar(160)
  phone   String? @db.VarChar(40)
  agents  Agent[]

  @@map("agencies")
}

model Agent {
  id       Int       @id @default(autoincrement())
  agencyId Int       @map("agency_id")
  agency   Agency    @relation(fields: [agencyId], references: [id])
  fullName String    @map("full_name") @db.VarChar(160)
  email    String    @unique @db.VarChar(160)
  listings Listing[]

  @@map("agents")
}

/// One row per unit of real estate, whether or not it is for sale today
model Property {
  id        Int       @id @default(autoincrement())
  address   String    @db.VarChar(240)
  postcode  String    @db.VarChar(12)
  bedrooms  Int
  floorArea Decimal   @map("floor_area") @db.Decimal(8, 2)
  features  Feature[]
  listings  Listing[]

  @@index([postcode])
  @@map("properties")
}

model Feature {
  id         Int        @id @default(autoincrement())
  label      String     @unique @db.VarChar(60)
  properties Property[]

  @@map("features")
}

model Listing {
  id         Int          @id @default(autoincrement())
  propertyId Int          @map("property_id")
  property   Property     @relation(fields: [propertyId], references: [id])
  agentId    Int          @map("agent_id")
  agent      Agent        @relation(fields: [agentId], references: [id])
  state      ListingState @default(DRAFT)
  price      Decimal      @db.Decimal(12, 2)
  listedOn   DateTime     @default(now()) @map("listed_on")
  viewings   Viewing[]

  @@map("listings")
}

model Viewing {
  id        Int      @id @default(autoincrement())
  listingId Int      @map("listing_id")
  listing   Listing  @relation(fields: [listingId], references: [id], onDelete: Cascade)
  visitor   String   @db.VarChar(160)
  scheduled DateTime

  @@map("viewings")
}

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

enum ListingState {
  DRAFT
  LIVE
  UNDER_OFFER
  SOLD
}

/// Estate agencies we work with
model Agency {
  id      Int     @id @default(autoincrement())
  name    String  @db.VarChar(160)
  phone   String? @db.VarChar(40)
  agents  Agent[]

  @@map("agencies")
}

model Agent {
  id       Int       @id @default(autoincrement())
  agencyId Int       @map("agency_id")
  agency   Agency    @relation(fields: [agencyId], references: [id])
  fullName String    @map("full_name") @db.VarChar(160)
  email    String    @unique @db.VarChar(160)
  listings Listing[]

  @@map("agents")
}

/// One row per unit of real estate, whether or not it is for sale today
model Property {
  id        Int       @id @default(autoincrement())
  address   String    @db.VarChar(240)
  postcode  String    @db.VarChar(12)
  bedrooms  Int
  floorArea Decimal   @map("floor_area") @db.Decimal(8, 2)
  features  Feature[]
  listings  Listing[]

  @@index([postcode])
  @@map("properties")
}

model Feature {
  id         Int        @id @default(autoincrement())
  label      String     @unique @db.VarChar(60)
  properties Property[]

  @@map("features")
}

model Listing {
  id         Int          @id @default(autoincrement())
  propertyId Int          @map("property_id")
  property   Property     @relation(fields: [propertyId], references: [id])
  agentId    Int          @map("agent_id")
  agent      Agent        @relation(fields: [agentId], references: [id])
  state      ListingState @default(DRAFT)
  price      Decimal      @db.Decimal(12, 2)
  listedOn   DateTime     @default(now()) @map("listed_on")
  viewings   Viewing[]

  @@map("listings")
}

model Viewing {
  id        Int      @id @default(autoincrement())
  listingId Int      @map("listing_id")
  listing   Listing  @relation(fields: [listingId], references: [id], onDelete: Cascade)
  visitor   String   @db.VarChar(160)
  scheduled DateTime

  @@map("viewings")
}

Your diagram appears here.

Replace the example with your schema, then Export → DBML — it copies to the clipboard.

The DBML it writes

The real export of the schema above, trimmed to two tables and their references:

// Generated with erddocs.com — paste SQL, get an ER diagram and a data dictionary
Enum ListingState {
  DRAFT
  LIVE
  UNDER_OFFER
  SOLD
}

Table agencies {
  id Int [pk, increment]
  name VarChar(160) [not null]
  phone VarChar(40)

  Note: 'Estate agencies we work with'
}

Table _FeatureToProperty {
  A int [not null]
  B int [not null]

  Note: 'Implicit many-to-many join table (created by Prisma)'
}

Ref: agents.agency_id > agencies.id
Ref: _FeatureToProperty.A > features.id
Ref: _FeatureToProperty.B > properties.id

A generator, or a paste

ErdDocs converts the file in front of you: paste schema.prisma, read the diagram, copy the DBML, and nothing is added to the project. The usual alternative is a Prisma generator — add a block to schema.prisma, install the package, run prisma generate, and a .dbml file appears in your project — which is the right shape when the conversion belongs in your build, regenerated on every schema change, committed and reviewed. The two answer different questions: a generator keeps a file in sync, ErdDocs answers the one you have now.

A generator is a poor fit for the other case: a schema someone sent you, a file open in a pull request, a repository you have not decided to work on yet. Adding a dependency and a generator block to answer a one-off question is a lot of ceremony, and on a schema you do not own it is not available at all.

Look before you convert

ErdDocs shows you the conversion while it makes it. Every other route is text in, text out — which is fine until the question stops being "did it convert" and becomes "did it convert correctly": did the many-to-many become the table Prisma really creates, did the optional relation stay optional, is the relation I care about even there.

The diagram above and the DBML below it are the same parsed schema, so looking at one tells you about the other. In the example, features on a property and properties on a feature are an implicit many-to-many, and Prisma answers that with a real table — _FeatureToProperty, two columns, a key to each side. It is in the diagram and in the DBML for the same reason: your database will have it.

FAQ

How is this different from prisma-dbml-generator?

That package is a Prisma generator: you add a generator block to schema.prisma, install it, and run prisma generate, which writes a .dbml file into your project. It is the right tool when the conversion belongs in your build. This is for the times it does not — a schema someone sent you, a file in a pull request, or a one-off you would rather not add a dependency for. Paste it, look at the diagram, copy the DBML.

What does the DBML keep?

Tables and columns with their types as the database gets them, primary keys including composite ones, unique constraints, indexes, defaults, and every relation as a Ref line. Prisma /// documentation comments become DBML notes, so a documented schema stays documented. Enums come across as enum blocks.

Does it include the join tables Prisma creates?

Yes, and that is often the reason to convert at all. An implicit many-to-many in Prisma produces a real table named _ModelAToModelB with A and B columns; it appears in no model, and a DBML file that omits it describes a database you do not have. It is written out like any other table.

Can I paste the result into dbdiagram.io?

That is what it is for. The output is plain DBML, so it goes into dbdiagram, dbdocs, or any tool that reads the language. The round trip is tested in both directions: what this exporter writes, our own DBML parser reads back into the same schema.

Is it free?

Converting is free at any schema size, with no account and nothing installed — the 25-table limit applies to how many tables get drawn, not to what gets converted. The text carries one comment line naming ErdDocs; $9 once removes it, lifts the limit and unlocks the data dictionary.

Prisma to PlantUML — the same schema for a UML toolchain.
Prisma schema to ER diagram — the database a schema.prisma generates, drawn.
Prisma schema to SQL — CREATE TABLE statements from the same file.
DBML to ER diagram — the other direction, and what DBML looks like drawn.
Example schemas — eleven domains to paste and convert.
SQL to ER diagram — the tool with every format it reads and writes.