DBML to Mermaid

Paste DBML and take away a Mermaid erDiagram — with the diagram drawn beside it, so you can see what you are about to commit to a README instead of finding out after you push. Nothing installed, nothing uploaded.

Your schema

Table artists {
  id bigserial [pk]
  name varchar(160) [not null]
  country char(2)

  Note: 'Performers; a band is one row'
}

Table albums {
  id bigserial [pk]
  artist_id bigint [not null, ref: > artists.id]
  title varchar(200) [not null]
  released date
  label varchar(120)
}

Table tracks {
  id bigserial [pk]
  album_id bigint [not null, ref: > albums.id]
  position int [not null]
  title varchar(200) [not null]
  seconds int [not null]

  Indexes {
    (album_id, position) [unique]
  }

  Note: 'One row per recording, ordered inside its album'
}

Table listeners {
  id bigserial [pk]
  handle varchar(40) [not null, unique]
  joined date [not null]
}

Table playlists {
  id bigserial [pk]
  listener_id bigint [not null, ref: > listeners.id]
  name varchar(120) [not null]
  is_public boolean [not null, default: false]
}

Table playlist_tracks {
  playlist_id bigint [not null, ref: > playlists.id]
  track_id bigint [not null, ref: > tracks.id]
  added_at timestamptz [not null, default: `now()`]

  Indexes {
    (playlist_id, track_id) [pk]
  }
}

Table artists {
  id bigserial [pk]
  name varchar(160) [not null]
  country char(2)

  Note: 'Performers; a band is one row'
}

Table albums {
  id bigserial [pk]
  artist_id bigint [not null, ref: > artists.id]
  title varchar(200) [not null]
  released date
  label varchar(120)
}

Table tracks {
  id bigserial [pk]
  album_id bigint [not null, ref: > albums.id]
  position int [not null]
  title varchar(200) [not null]
  seconds int [not null]

  Indexes {
    (album_id, position) [unique]
  }

  Note: 'One row per recording, ordered inside its album'
}

Table listeners {
  id bigserial [pk]
  handle varchar(40) [not null, unique]
  joined date [not null]
}

Table playlists {
  id bigserial [pk]
  listener_id bigint [not null, ref: > listeners.id]
  name varchar(120) [not null]
  is_public boolean [not null, default: false]
}

Table playlist_tracks {
  playlist_id bigint [not null, ref: > playlists.id]
  track_id bigint [not null, ref: > tracks.id]
  added_at timestamptz [not null, default: `now()`]

  Indexes {
    (playlist_id, track_id) [pk]
  }
}

Your diagram appears here.

Replace the example with your file, then Export → Mermaid — it copies to the clipboard.

The Mermaid it writes

The real export of the schema above, trimmed to three entities so it fits here:

%% Generated with erddocs.com — paste SQL, get an ER diagram and a data dictionary
erDiagram
  artists {
    bigserial id PK
    varchar name
    char country
  }
  albums {
    bigserial id PK
    bigint artist_id FK
    varchar title
    date released
    varchar label
  }
  tracks {
    bigserial id PK
    bigint album_id FK
    int position
    varchar title
    int seconds
  }
  albums }o--|| artists : "artist_id"
  tracks }o--|| albums : "album_id"

Converting blind is the normal way

ErdDocs converts and shows you the result at the same time. The other tools for this job take text and return text, which is fine when the schema is six tables and you wrote them this morning. It stops being fine when the file came from someone else, or from a database, and the question you actually have is not "did it convert" but "did it convert correctly" — did that one-to-many come out pointing the way I meant, did the junction table keep both of its keys, is the relation I care about even there.

Answering that with a blind converter means a round trip through some renderer. Here the diagram above and the Mermaid below are the same parsed schema, so looking at one tells you about the other. If a relation is missing from the picture, it will be missing from the text, and you find that out before the README does.

What survives the trip

DBML is the richer language of the two, so a conversion loses things. Being explicit about which is more useful than pretending otherwise:

Carried across — tables and columns, the key markers PK, FK and UK, every relation, and the cardinality that makes a crow’s foot point the right way.
Left behind — the size of a type (varchar(200) becomes varchar), defaults, nullability, notes and indexes. Mermaid’s erDiagram grammar has nowhere to put them.
Where they went instead — the data dictionary keeps all of it, and the PlantUML export keeps sizes and nullability. Pick the output by what the reader needs, not by which one you started with.

FAQ

What does the Mermaid output keep, and what does it drop?

It keeps the tables, the columns, their normalized types, the PK, FK and UK markers, and every relation with its cardinality. It drops what Mermaid’s erDiagram grammar has no place for: the size of a type (varchar(200) becomes varchar), defaults, nullability, comments and indexes. That is Mermaid’s limit rather than the conversion’s, which is why ErdDocs keeps the data dictionary and the PlantUML export next to it.

Will the result render on GitHub?

Yes. GitHub renders mermaid code blocks natively, so pasting the export into a README shows a diagram rather than a wall of text. Identifiers are sanitized on the way out — Mermaid rejects spaces and most punctuation in attribute names — so an export never fails to render because a column was called "order total".

Can it go the other way, Mermaid to DBML?

Yes. Mermaid erDiagram is also an input format, so you can paste a diagram out of a README and export DBML from it, or draw it, or turn it into a data dictionary. The parser and the exporter are tested against each other in both directions.

Is my file uploaded anywhere?

No. The conversion is JavaScript running in your browser: the DBML is read on your machine and the Mermaid is produced there too. There is no account and no server to leave it on.

Is it free?

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

DBML to ER diagram — the same file drawn, and turned into a printable dictionary.
Mermaid ER diagram generator — starting from SQL, Prisma or ORM models instead.
SQL to PlantUML — the export that keeps sizes and nullability.
Prisma schema to ER diagram — for schemas that live in schema.prisma.
Example schemas — eleven domains to paste and convert.
SQL to ER diagram — the tool with every format it reads and writes.