ErdDocs

Prisma to DBML

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

Your schema

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. You add a block to schema.prisma, install the package and run prisma generate, and a .dbml file appears in your project.

A generator is a poor fit for 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. 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. That is fine until you need to check that it converted correctly. A many-to-many should become the table Prisma really creates, and an optional relation should stay optional. The relation you care about may not be there at all.

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. Prisma answers that with a real table, _FeatureToProperty, with two columns and 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. This page needs none of that. It covers 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. An implicit many-to-many in Prisma produces a real table named _ModelAToModelB with A and B columns. It appears in no model. 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. Paying $9 once removes it, lifts the limit and unlocks the data dictionary.

Related