A database design tool for modeling schemas as a team

Design is a conversation, not a drawing

A schema is cheap to change on a whiteboard and expensive to change in production. Database design is the work that happens in between, and most of it is people agreeing. DB Planner is built around that loop:

1. Model. Write the tables, keys, and relationships as DBML, or start from SQL you already have.
2. Review. The ER diagram is drawn from the model, so the team discusses the real thing.
3. Decide. Record why a column exists, or why a table was split, as a note right where it applies.
4. Hand off. Export SQL for your database, or C# models for your application.

Model in readable text

The model is DBML: a short language for tables and relationships that reads like a description of the schema rather than the commands that build it. Constraints, defaults, enums, and notes all live in the same text, so a reviewer reads one file instead of a migration history.

Table accounts {
  id uuid [pk]
  name varchar [not null]
}

Table invoices {
  id uuid [pk]
  account_id uuid [not null, ref: > accounts.id]
  status invoice_status [not null]
  total_cents int [not null, note: 'Integer cents. Never store money as a float.']

  Note: 'One row per billing period. Voided invoices are kept, never deleted.'
}

Enum invoice_status {
  draft
  open
  paid
  void
}

Both notes in that snippet render on the diagram: the table note in a footer on the invoices card, the column note behind an icon beside total_cents. The decision travels with the schema instead of living in a chat thread. More on the language in the DBML editor.

Split a large schema by domain

Real schemas outgrow one file. Put billing, identity, and catalog in documents of their own and DB Planner resolves every document in a project together, so a foreign key in one file points at a table in another with no import lines to keep in sync. Importing SQL works the same way: each database schema, such as public or auth, becomes its own document, and the references between them still draw.

Put the system next to the schema

Tables are only half a design. A project can also hold Mermaid class diagrams and flowcharts, and they draw onto the same board as the ER diagram. A group, a labelled frame, can hold any cards together: the checkout flowchart and the orders and payments tables it writes to, in one place a reviewer can see at once. Grouping is board layout, so it never edits the schema or the diagram text.

Roles that match responsibility

Organizations have owner, admin, and member roles, and each project grants editor or viewer access. The people designing the schema edit it; the people building against it see the same board, live, without being able to change it. Real-time collaboration needs Pro and an organization; the owner’s seat is free while Pro is active, and each added member is $5 a month. See pricing for the details.

Hand off as working code

• SQL for PostgreSQL, MySQL, or SQL Server, with a list of anything that does not survive the trip to that dialect, before you run it.
• C# models with Entity Framework annotations or as plain POCOs, with naming and namespace options to match your codebase.
• DBML for the repository, so the design is versioned next to the code.
• An image of the board for the design doc.

Coming from an existing database instead of a blank page? Start by turning its SQL into an ER diagram, then design from there.