A DBML editor with a live ER diagram

An editor that knows DBML

The editor is CodeMirror, set up for DBML: syntax highlighting, bracket matching and auto-closing, auto-indent, and an in-editor find that highlights every match. Parse errors appear with the line number of the problem, and the diagram reloads as you type, so a broken reference shows up the moment you write it rather than at export time.

Undo and redo use the standard shortcuts on the board as well as in the text, and the same editor handles Mermaid when a project holds class diagrams or flowcharts.

DBML on one screen

Most of what a schema needs fits in a handful of constructs. This is a working reference you can paste into a project:

// A table, its columns, and column settings
Table posts {
  id integer [pk, increment]
  title varchar [not null]
  status post_status [default: 'draft']
  author_id integer [ref: > users.id]   // many posts to one user
  body text [note: 'Markdown, rendered on read']
  created_at timestamp [default: `now()`]

  Note: 'A table note renders on the diagram'
}

Table users {
  id integer [pk, increment]
  email varchar [unique, not null]
}

Table post_tags {
  post_id integer
  tag varchar
}

// Relationship operators
//   >   many-to-one      <   one-to-many
//   -   one-to-one       <>  many-to-many
Ref: post_tags.post_id > posts.id

// An enum, drawn as its own card
Enum post_status {
  draft
  published
  archived
}

New to the language? What is DBML? explains the syntax and why teams use it, and DBML vs SQL covers when to write each.

One schema, many files

A single DBML file stops being pleasant somewhere around fifty tables. In DB Planner a project holds as many DBML documents as you like and resolves them together, so a reference in one file finds its table in another with no import lines to write or keep in sync:

Table albums {
  id uuid [pk]
  title varchar [not null]
}

Table tracks {
  id uuid [pk]
  album_id uuid [ref: > albums.id]
}

tracks.album_id resolves to albums because both files belong to the same project. Files that already carry dbdiagram-style use * from './file' lines work too: the lines are recognized and ignored.

Coming from dbdiagram.io

It is the same language, so a dbdiagram.io schema pastes straight in. What changes is around it: multi-file schemas, a shared board with roles, and exports to C# models as well as SQL. The DB Planner vs dbdiagram.io comparison has the detail, including where dbdiagram.io is the better fit.

From DBML to everything else

• SQL for PostgreSQL, MySQL, or SQL Server, with dialect warnings listed first.
• C# models with Entity Framework annotations or as plain POCOs.
• An image of the diagram for documentation.
• DBML files to commit next to the code that uses them.

Going the other way, from an existing database to DBML, is an import: turn SQL into an ER diagram and the DBML comes with it.

Share it read-only

Not everyone who needs the schema should be able to change it. Give a teammate viewer access to a project and they see the live diagram and the DBML behind it, always current, without an edit button in sight.