An ER diagram tool built on your real schema

What an ER diagram shows

An entity relationship diagram (ERD) is a map of a database. Each entity is a table, drawn as a box listing its columns. Each relationship is a line between two tables, usually a foreign key in one pointing at the primary key of the other. The ends of the line say how many rows on each side can take part: one customer has many orders, each order belongs to exactly one customer.

That makes an ERD the fastest way to understand a schema you did not write, and the clearest way to agree on one you are about to build. It is also why the diagram has to stay accurate: an ERD that drifted from the real schema is worse than none.

How DB Planner draws it

• Tables as cards. Every column shows its type, with PK and FK badges and a marker on not-null fields.
• Crow’s foot relationship lines. A single tick marks the "one" side and a crow’s foot marks the "many" side, and each line runs from the referencing column to the column it references, not just from table to table.
• Enums as their own cards. Enum-typed columns are highlighted, so the allowed values are one glance away.
• Hover to trace. Hovering a table highlights every relationship it takes part in, which is how you find your way around a schema with a hundred tables.
• Notes where the questions are. Table and column notes written in the schema render on the card, and sticky notes can go anywhere on the board.

Four ways to start an ER diagram

1. Write it. Type tables in DBML, a short, readable schema language, in the built-in DBML editor. The diagram updates as you type.
2. Import it. Paste a schema dump from PostgreSQL, MySQL, or SQL Server and turn the SQL into an ER diagram in one step.
3. Copy one. Open a database schema template, real ER diagram examples for e-commerce, banking, hospitals, and more, and copy it into your workspace.
4. Ask for one. Connect Claude or Cursor and let the assistant design the schema with you over MCP.

This is all the DBML it takes to draw two related tables and an enum:

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

Table orders {
  id uuid [pk]
  user_id uuid [not null, ref: > users.id]
  status order_status
}

Enum order_status {
  pending
  paid
  shipped
}

ref: > users.id says each order points at one user, so the line between orders.user_id and users.id gets a crow’s foot at the orders end.

Text first, not drag and drop

Most ER diagram makers ask you to draw boxes and then connect them. DB Planner works the other way round: the schema text is the source of truth and the diagram is drawn from it. That means a change is one edited line rather than a re-routed connector, the schema can be reviewed and diffed like code, and the diagram can never quietly disagree with it.

Layout is still yours. Drag tables where they make sense, collapse the ones you are not discussing, or auto-arrange the whole board with one click. Positions are saved on the board, not in the schema, so tidying the picture never edits the design.

Built for a team, not one person

An ER diagram is usually a conversation. Everyone signed in to a project sees the same board, with live presence, so a review happens on the diagram itself. Organizations have owner, admin, and member roles, and each project grants editor or viewer access, so the people who should read the schema can, without being able to change it. Real-time collaboration comes with an organization, at $5 per seat.

A board can also hold Mermaid class diagrams and flowcharts next to the tables, so the process that writes to orders can sit beside orders. That is what a database design tool for a whole system looks like.

Take the diagram with you

Export the board as an image for a README, a wiki, or a design doc. Export the schema as SQL for PostgreSQL, MySQL, or SQL Server, with a warning for anything that does not carry over to that dialect, as DBML, or as C# model classes with Entity Framework annotations. The diagram stays the place the schema is designed, and every other format comes from it.