ERD Designer

Design a relational schema without a database server: add tables, give them columns with types, keys and defaults, then connect them with relationships. The entity relationship diagram redraws as you type, and the same model exports as CREATE TABLE DDL for MySQL, PostgreSQL, SQL Server, SQLite or Oracle, as Mermaid erDiagram source, or as portable schema JSON you can re-import here or open in the Migration Generator. Everything runs locally.
What is an ERD? ERD is short for entity relationship diagram, and it is the design drawing of a database rather than a record of a finished one. A useful comparison is a building blueprint: the running database is the building, the ERD is the blueprint, and nobody pours concrete first and measures afterwards. This page is the drawing table for that blueprint — you shape the model here, and the DDL, the Mermaid source and the schema JSON are all printed from that one model, so the picture cannot drift away from the SQL it produced.
The same diagram at three levels. A conceptual ERD names only the things that matter and how they relate, in words a non-programmer can check. A logical ERD adds the keys that identify each thing and resolves many-to-many links, while staying free of any engine’s dialect. A physical ERD fills in what one particular product demands — type widths, defaults, nullability, unique constraints, delete rules — which is the level you export here when you pick MySQL, PostgreSQL, SQL Server, SQLite or Oracle.
Where the boxes come from. Read a description of the system and underline the nouns: customer, invoice, product, shipment. Those are the tables. The facts and qualities attached to a noun — an invoice date, a unit price, an e-mail address — are its columns. A verb that ties two nouns together, as in “an order is placed by a customer”, is a relationship, and it is stored by copying the identifying key of the parent row into the child row as a foreign key.
When a link is many-to-many. One recipe uses many ingredients and one ingredient shows up in many recipes, so neither table can keep the other’s key without repeating itself. The answer is a third entity whose only job is to pair them — the junction (or associative) table, holding one foreign key for each side, often with that pair of keys as its own primary key. A model that is mostly such pairing tables is completely normal: a many-to-many line on a whiteboard always has to become a box in the real schema.
Why bother before the DDL exists. A wrong line on a drawing costs a minute to rub out; the same mistake found after release costs a migration over live data. A diagram is also the one artefact non-developers can review, and relationship faults — a cardinality the wrong way round, a missing unique key, child rows that can be left without a parent — show up as obviously bad lines here, while in a 400-line DDL file they hide among the constraints.
Forward or reverse? This designer goes forward: model first, DDL out. The sibling SQL to ERD page goes the other way — paste existing CREATE TABLE statements and it rebuilds the diagram, which is the quicker route once the database already exists.
1 — Tables
Edit Table name Columns Relations
2 — Columns
Column Type PK AI NN UQ Default
PK = primary key, AI = auto increment / identity, NN = not null, UQ = unique
3 — Relationships (foreign keys)
Child table Child column Parent table Parent column On delete
A foreign key turns into a CONSTRAINT ... FOREIGN KEY line in the DDL.
4 — Export
Mermaid erDiagram source
The JSON model is the interchange format for the database tool family: paste it into the Migration Generator as a before/after schema, or re-import it here to keep editing later.