SQL to ERD

Paste one or more CREATE TABLE statements and this tool draws the schema: every table becomes an entity, columns become attributes tagged PK / FK, and FOREIGN KEY constraints become relationship lines. When a schema declares no foreign keys, columns such as customer_id are offered as inferred relations you can keep or drop. Copy the Mermaid erDiagram source or export the diagram as SVG / PNG. Everything runs locally — no schema ever leaves your browser.
What is an ERD? ERD stands for Entity Relationship Diagram — a picture of how a database is organised. It is drawn from three kinds of shapes: entities (the tables, drawn as boxes), attributes (the columns listed inside a box) and relationships (the lines that join two boxes). The technique comes from Peter Chen’s 1976 entity-relationship model and is still the usual way to sketch a schema before writing any DDL: a good ERD shows at a glance which tables exist, what each row stores, and how a row in one table points at a row in another — readable by people who do not want to read SQL.
Entity — one thing the system keeps data about, such as a customer, an order or a product. In a relational database each entity becomes one table.
Attribute — one fact recorded for every row of an entity, such as a name, a price or a date. Each attribute becomes one column.
Relationship — an association between two entities, implemented by a foreign key: the child table stores the parent’s key, and the diagram turns that column into a line.
PK / FK — a primary key (PK) identifies each row of a table uniquely; a foreign key (FK) holds the primary key of another table and is what a relationship line represents.
Cardinality — how many rows are allowed at each end of a line: one-to-one, one-to-many or many-to-many. This page draws the crow’s-foot notation that Mermaid uses (see the legend in step 4).
Notations: Chen notation uses diamonds for relationships and ellipses for attributes; crow’s-foot notation (the one drawn here) compresses an entity into a single box with its attributes listed inside and marks the many end of a line with a three-pronged “crow’s foot”; UML class diagrams describe the same structure with classes, operations and multiplicities. All three say the same thing about the schema — only the symbols differ.
1 — Table schema (DDL)
2 — Entities
Draw Table Columns Relations Attributes
No tables parsed yet.
3 — Relationships
Use Child (many) Parent (one) Source
No relationships yet.
Add a relationship by hand:
→
4 — Diagram
Mermaid erDiagram source
How relations are read: a foreign key on the child table produces PARENT ||--o{ CHILD. Entities and attributes keep their DDL names, with characters that Mermaid cannot draw (spaces, dashes) shown as underscores. Types are simplified to their base word (DECIMAL(10,2) → DECIMAL) because the diagram syntax does not take parameters.
Cardinality symbols (crow’s foot): the mark next to an entity says how many rows may stand on that end of the line — || exactly one, o| zero or one, o{ zero or many, |{ one or many. So PARENT ||--o{ CHILD reads “one parent row can be referenced by zero, one or many child rows, and every child row points at exactly one parent” — the classic one-to-many link.
Many-to-many is never a single line: a product can appear in many orders and an order can hold many products, so the schema stores a join table (order_items) whose two foreign keys become two one-to-many lines. Read through that middle box and the many-to-many is there.