SQL to ER diagram

Most databases already have a diagram — it is just written as SQL. A CREATE TABLE script describes every entity, every key and every relationship in your schema; it simply does so in a form that is hard to read. Converting that script into an entity-relationship diagram is a mechanical translation, and it is what ERDGenerator does: paste your SQL, and a parsed, editable diagram comes out the other side. Free, no sign-up, and the parsing happens in your browser.

What the conversion actually involves

A schema is a graph, and SQL encodes that graph across several kinds of statements. Turning it into an ERD means recovering each piece:

  • Tables become entities. Each CREATE TABLE maps to a box in the diagram, with its columns, their types, and nullability carried over.
  • Primary keys become identifiers. A column marked PRIMARY KEY — inline or as a table-level constraint — gets a key badge so you can spot it at a glance.
  • Foreign keys become edges. Every REFERENCES clause, whether declared inline on a column or in a separate ALTER TABLE ... ADD FOREIGN KEY statement, becomes a line between two tables.
  • Cardinalities come from the constraints. A foreign key that is also UNIQUE is a one-to-one relation; a plain foreign key is one-to-many; and a join table with a composite primary key is detected as a many-to-many relation between the two tables it links.

Defaults, unique constraints and nullable columns carry over too, so the diagram is a faithful view of the schema rather than a rough sketch of it.

Supported SQL dialects

ERDGenerator parses four dialects: PostgreSQL, MySQL, SQLite and SQL Server. The parser is a real SQL grammar, not a pile of regular expressions, so it handles the details that break simpler tools: quoted identifiers, schema-qualified table names, and dump-style output where every foreign key arrives later as its own ALTER TABLE statement. That last case matters in practice — a pg_dump or mysqldump export rarely puts the constraints where you would expect, and the diagram should still come out right.

DBML and Prisma schemas are supported as well, so you can bring in a diagram defined with dbml or an ORM schema without going through SQL first.

A worked example

Take a small blog schema — four tables, one of them a join table:

blog.sql — PostgreSQL
SQL
CREATE TABLE users (
  id          serial PRIMARY KEY,
  email       varchar(255) NOT NULL UNIQUE,
  created_at  timestamptz DEFAULT now()
);

CREATE TABLE posts (
  id          serial PRIMARY KEY,
  author_id   integer NOT NULL REFERENCES users(id),
  title       varchar(200) NOT NULL,
  published   boolean DEFAULT false
);

CREATE TABLE tags (
  id    serial PRIMARY KEY,
  name  varchar(50) NOT NULL UNIQUE
);

CREATE TABLE post_tags (
  post_id  integer NOT NULL REFERENCES posts(id),
  tag_id   integer NOT NULL REFERENCES tags(id),
  PRIMARY KEY (post_id, tag_id)
);

Parsed and laid out, this produces a four-entity diagram. users, posts and tags appear as boxes with their columns; id carries a key badge, and email and name carry unique badges. The author_id reference draws an edge from posts to users, read as one-to-many: one user, many posts.

The interesting one is post_tags. Two foreign keys pointing at posts and tags, plus a composite primary key, is the signature of a junction table — so instead of a fourth box with two incoming edges, you get a single many-to-many relation between posts and tags. The diagram shows the shape of your data, not just the shape of your DDL.

What you can do with the result

The diagram is not a picture — it opens in a visual editor. From there:

  • Edit it. Drag tables around, rename or add columns, and draw new relationships with explicit cardinalities (1:1, 1:N, N:M). Fifty levels of undo, one keystroke at a time.
  • Export it. PNG and SVG for documentation, runnable SQL for PostgreSQL, MySQL, SQLite or SQL Server, DBML, a first-draft Prisma schema, or portable JSON.
  • Share it. Publish a read-only link so teammates or clients can explore the schema — no account needed on their side, and you can revoke access at any time.

Common questions

Does my SQL leave my browser?

No. For SQL, DBML and Prisma input, the parsing runs entirely in your browser — the diagram exists before anything is sent anywhere. The project is created only when you open the editor, and it is tied to an anonymous browser cookie rather than an account.

Will it handle a large production schema?

A full database dump is exactly the use case the parser was built for, including the dump-style ALTER TABLE foreign keys it produces. Very large schemas make any diagram crowded, so plan on using the layout tools — auto-arrange, drag, zoom — and pruning anything you do not need before sharing.

What if my script has INSERT statements or comments?

The converter only reads the DDL — the CREATE TABLE, ALTER TABLE and constraint definitions. Data rows and comments are ignored, so you can paste a file as it came out of a dump without cleaning it up first.

Can I go the other way, from diagram to SQL?

Yes. Export produces runnable DDL for all four dialects, plus DBML and a first-draft Prisma schema, so a diagram you adjusted by hand can still land back in your database.

Go further

If you want the background rather than the tool, the guides cover the same ground in more depth: how to turn SQL into an ER diagram step by step, a dedicated PostgreSQL guide, ready-made schemas to start from in the examples library, or a template for a common domain. Or paste your own script below and see the diagram: