Turn SQL into an ER diagram

From SQL to ER diagram in four steps

1. Export the schema only. Dump the structure of the database without its data, using pg_dump --schema-only, mysqldump --no-data, or Generate Scripts in SQL Server Management Studio.
2. Import the SQL into DB Planner. Paste the dump or drop the .sql file into the SQL import. The dialect is detected from the syntax, so there is nothing to choose.
3. Review the generated DBML. Each database schema becomes its own DBML document, with foreign keys between schemas still resolving. The DBML is yours to edit from here.
4. Arrange and share the ER diagram. Auto-arrange the board, drag the important tables together, add notes, and invite the team to the project.

Get the schema out of your database

You want the structure, not the rows. Each database has a way to dump just that.

PostgreSQL

pg_dump --schema-only --no-owner --no-privileges -d mydb > schema.sql

MySQL

mysqldump --no-data mydb > schema.sql

SQL Server

In SQL Server Management Studio, right-click the database, choose Tasks, then Generate Scripts. Script the tables you want, and under Advanced set Types of data to script to Schema only.

What the conversion looks like

A small PostgreSQL schema goes in:

CREATE TYPE order_status AS ENUM ('pending', 'paid', 'shipped');

CREATE TABLE users (
  id uuid PRIMARY KEY,
  email varchar(255) NOT NULL UNIQUE,
  created_at timestamp with time zone NOT NULL DEFAULT now()
);

CREATE TABLE orders (
  id uuid PRIMARY KEY,
  user_id uuid NOT NULL REFERENCES users (id),
  status order_status NOT NULL
);

and comes out as DBML, shown here tidied for reading:

Enum order_status {
  pending
  paid
  shipped
}

Table users {
  id uuid [pk]
  email varchar(255) [not null, unique]
  created_at "timestamp with time zone" [not null, default: `now()`]
}

Table orders {
  id uuid [pk]
  user_id uuid [not null]
  status order_status [not null]
}

Ref: orders.user_id > users.id

Column types come across exactly as they were written, including multi-word types like timestamp with time zone, which some converters quietly shorten to timestamp. The REFERENCES clause becomes a Ref, and that becomes the line on the diagram with a crow’s foot at the orders end.

What converts, and what does not

Tables, columns and their types, primary and foreign keys (inline or added later with ALTER TABLE), unique and not-null constraints, defaults, indexes, and enums all come across. A database with several schemas is split into one DBML document per schema, and references between them still resolve.

Views, functions, stored procedures, and triggers are not part of DBML, so the import skips them, and no row data is ever read. Only PostgreSQL, MySQL, and SQL Server dumps can be imported.

Keep the diagram in step with the database

An ER diagram is only useful while it is true. When migrations land, import the new dump into the project, or go the other way: design the change in DBML, review it on the diagram, and export the SQL. For a longer walk through arranging and annotating a large import, read how to visualize a SQL database schema, and for when to reach for each language, DBML vs SQL.