SQL to ER diagram: paste CREATE TABLE, get a crow's foot diagram

How does the SQL get turned into an ER diagram?

A small SQL parser (not a regular expression) tokenises your script, reads every CREATE TABLE and ALTER TABLE … ADD FOREIGN KEY, and builds a model of tables, columns, keys and references. Each table becomes an entity box; each foreign key becomes a relationship line from the referenced (parent) table to the table that holds the key (child). The crow's-foot marks come from the constraints on the foreign-key column, using the rules in the table below.

1. Tokenise — identifiers (bare, "quoted", `backticked`, [bracketed]), strings, numbers, punctuation; --, # and /* */ comments are skipped.
2. Parse statements — column definitions with types, inline constraints, table-level constraints; everything else (CREATE INDEX, INSERT, SET, dialect options such as ENGINE=InnoDB) is skipped and listed in the notes.
3. Resolve — table-level primary keys and unique constraints are applied to their columns; foreign keys are matched to the referenced tables by name (case-insensitive).
4. Infer cardinality — from NOT NULL, UNIQUE and composite primary keys (rules below).
5. Emit — a diagram spec for the free image API, the two tables above, and Mermaid erDiagram code with the matching crow's-foot arrows.

Which SQL syntax does the converter understand?

The common DDL subset shared by Postgres, MySQL/MariaDB, SQLite and SQL Server. Anything outside it is skipped per statement — the rest of the script still converts — and a parse error reports the line and what was expected.

How is the cardinality inferred from the constraints?

A foreign key always points from the child row to exactly one parent row at most, so the child side is never "many parents". What the constraints decide is whether that parent is mandatory and whether the parent may have more than one child. The table reads parent → child, the same direction as the Mermaid arrows it produces.

Strictly, the child-side mark can never be proven from DDL alone: a database does not record that every customer must have at least one order, so the tool never claims a mandatory many (|{). Promote it by hand in the Mermaid code or the studio when your business rule says so. The full notation is on the crow's foot notation page.

What does the Mermaid erDiagram output look like?

Each table becomes an entity block listing type name KEY per column (PK, FK, UK, or combinations such as PK, FK), followed by one relationship line per foreign key, labelled with the FK column. The four-table sample produces this; it pastes straight into GitHub, Notion, Obsidian or the Mermaid live editor.

erDiagram
    users {
        SERIAL id PK
        VARCHAR(255) email UK
        VARCHAR(120) full_name
        TIMESTAMP created_at
    }
    orders {
        SERIAL id PK
        INTEGER user_id FK
        VARCHAR(20) status
        TIMESTAMP placed_at
    }
    order_items {
        INTEGER order_id PK, FK
        INTEGER product_id PK, FK
        INTEGER quantity
        INTEGER unit_cents
    }
    products {
        SERIAL id PK
        VARCHAR(40) sku UK
        VARCHAR(200) name
        INTEGER price_cents
    }
    users ||--o{ orders : "user_id"
    orders ||--o{ order_items : "order_id"
    products ||--o{ order_items : "product_id"
    %% order_items is a junction table: orders }o--o{ products

Mermaid attribute types cannot contain spaces or commas, so DECIMAL(10,2) is written DECIMAL(10_2) and TIMESTAMP WITH TIME ZONE becomes TIMESTAMP_WITH_TIME_ZONE; everything else is verbatim. Symbol meanings are on the ER diagram symbols page.

Related guides and generators