SQL to PlantUML

Paste a PostgreSQL or MySQL dump and copy PlantUML — entities with their keys, nullability and crow’s foot relations, ready for a .puml file. No Java, no Graphviz, no Docker and no database connection: the schema is parsed in your browser and never uploaded.

Your schema

CREATE TABLE users (
    id         bigserial    PRIMARY KEY,
    handle     varchar(40)  NOT NULL UNIQUE,
    email      varchar(160) NOT NULL UNIQUE,
    is_active  boolean      NOT NULL DEFAULT true
);

CREATE TABLE projects (
    id       bigserial    PRIMARY KEY,
    key      varchar(10)  NOT NULL UNIQUE,
    name     varchar(120) NOT NULL,
    lead_id  bigint       NOT NULL REFERENCES users(id)
);
COMMENT ON COLUMN projects.key IS 'Short prefix used in issue numbers, e.g. ERD-42';

CREATE TABLE issues (
    id           bigserial    PRIMARY KEY,
    project_id   bigint       NOT NULL REFERENCES projects(id),
    number       int          NOT NULL,
    title        varchar(240) NOT NULL,
    state        varchar(16)  NOT NULL DEFAULT 'open',
    reporter_id  bigint       NOT NULL REFERENCES users(id),
    assignee_id  bigint       REFERENCES users(id),
    parent_id    bigint       REFERENCES issues(id),
    opened_at    timestamptz  NOT NULL DEFAULT now(),
    closed_at    timestamptz,
    UNIQUE (project_id, number)
);
COMMENT ON TABLE issues IS 'Work items; parent_id links a sub-task to its parent';

CREATE TABLE labels (
    id      bigserial   PRIMARY KEY,
    name    varchar(40) NOT NULL UNIQUE,
    colour  char(6)     NOT NULL
);

CREATE TABLE issue_labels (
    issue_id  bigint NOT NULL REFERENCES issues(id),
    label_id  bigint NOT NULL REFERENCES labels(id),
    PRIMARY KEY (issue_id, label_id)
);

CREATE TABLE comments (
    id         bigserial   PRIMARY KEY,
    issue_id   bigint      NOT NULL REFERENCES issues(id),
    author_id  bigint      NOT NULL REFERENCES users(id),
    body       text        NOT NULL,
    posted_at  timestamptz NOT NULL DEFAULT now()
);

CREATE INDEX idx_issues_assignee ON issues(assignee_id);

CREATE TABLE users (
    id         bigserial    PRIMARY KEY,
    handle     varchar(40)  NOT NULL UNIQUE,
    email      varchar(160) NOT NULL UNIQUE,
    is_active  boolean      NOT NULL DEFAULT true
);

CREATE TABLE projects (
    id       bigserial    PRIMARY KEY,
    key      varchar(10)  NOT NULL UNIQUE,
    name     varchar(120) NOT NULL,
    lead_id  bigint       NOT NULL REFERENCES users(id)
);
COMMENT ON COLUMN projects.key IS 'Short prefix used in issue numbers, e.g. ERD-42';

CREATE TABLE issues (
    id           bigserial    PRIMARY KEY,
    project_id   bigint       NOT NULL REFERENCES projects(id),
    number       int          NOT NULL,
    title        varchar(240) NOT NULL,
    state        varchar(16)  NOT NULL DEFAULT 'open',
    reporter_id  bigint       NOT NULL REFERENCES users(id),
    assignee_id  bigint       REFERENCES users(id),
    parent_id    bigint       REFERENCES issues(id),
    opened_at    timestamptz  NOT NULL DEFAULT now(),
    closed_at    timestamptz,
    UNIQUE (project_id, number)
);
COMMENT ON TABLE issues IS 'Work items; parent_id links a sub-task to its parent';

CREATE TABLE labels (
    id      bigserial   PRIMARY KEY,
    name    varchar(40) NOT NULL UNIQUE,
    colour  char(6)     NOT NULL
);

CREATE TABLE issue_labels (
    issue_id  bigint NOT NULL REFERENCES issues(id),
    label_id  bigint NOT NULL REFERENCES labels(id),
    PRIMARY KEY (issue_id, label_id)
);

CREATE TABLE comments (
    id         bigserial   PRIMARY KEY,
    issue_id   bigint      NOT NULL REFERENCES issues(id),
    author_id  bigint      NOT NULL REFERENCES users(id),
    body       text        NOT NULL,
    posted_at  timestamptz NOT NULL DEFAULT now()
);

CREATE INDEX idx_issues_assignee ON issues(assignee_id);

Your diagram appears here.

Paste your own dump, then use Export → PlantUML — it copies to the clipboard.

What comes out

This is the real export of the schema above, trimmed to two entities so it fits on the page — same header, same markers, same relation lines:

@startuml
' Generated with erddocs.com — paste SQL, get an ER diagram and a data dictionary
hide circle
skinparam linetype ortho

entity "projects" as projects {
  *id : BIGSERIAL <<PK>>
  --
  *key : VARCHAR(10) <<UK>>
  *name : VARCHAR(120)
  *lead_id : BIGINT <<FK>>
}

entity "issues" as issues {
  *id : BIGSERIAL <<PK>>
  --
  *project_id : BIGINT <<FK>>
  *number : INT
  *title : VARCHAR(240)
  *state : VARCHAR(16)
  *reporter_id : BIGINT <<FK>>
  assignee_id : BIGINT <<FK>>
  parent_id : BIGINT <<FK>>
  *opened_at : TIMESTAMPTZ
  closed_at : TIMESTAMPTZ
}

projects }o--|| users : lead_id
issues }o--|| projects : project_id
issues }o--|| users : reporter_id
issues }o--|| users : assignee_id
issues }o--|| issues : parent_id
@enduml

Keys are marked, not guessed at by the reader — <<PK>>, <<FK>> and <<UK>>, with the primary key columns first and a rule under them.
Nullability is in the syntax — PlantUML’s leading * means mandatory, so assignee_id being optional is visible without a legend.
Types keep their size and precision — VARCHAR(240) stays 240 characters and NUMERIC(10,2) stays two decimal places. Nothing is flattened into a generic “string” or “number”. A self-reference like parent_id is drawn as a real line from a table to itself.
The header makes it an ER diagram — hide circle drops the class-diagram bubble, and skinparam linetype ortho gives right-angled edges.

Why this is usually a five-tool job

Search for a SQL-to-PlantUML converter and you find command-line projects: one needs a JVM, another a Graphviz binary on the PATH, a third a running database to reverse-engineer, and the friendliest of them still expects a container. That is a reasonable trade for a pipeline you run every week, and a poor one for the far more common case: you have a dump in front of you and you want the diagram now, on a machine where you would rather not install a JDK. ErdDocs is the whole toolchain for that case — one tab, nothing installed.

The other half of that trade is trust. A dump is your schema: table names, column names, the shape of the business. ErdDocs parses it inside the tab, so it never crosses a network — which a hosted converter cannot promise however good its intentions.

Getting the dump

01pg_dump --schema-only mydb > schema.sql for PostgreSQL, or mysqldump --no-data mydb > schema.sql for MySQL. Neither reads a single row of data.
02Paste the file above, or drop it onto the panel.
03Export → PlantUML, paste into your .puml file. Mermaid and DBML sit in the same menu if the target is a README or dbdiagram instead.

FAQ

Do I need Java, Graphviz or Docker?

No. ErdDocs parses the schema with JavaScript in the browser tab you already have open, and the PlantUML is text you copy. Every other route from SQL to PlantUML is a command-line tool that renders locally: ddl2plantuml, planter and SchemaCrawler all want a JVM, a Graphviz binary, a container, or a live database connection. You only need a PlantUML renderer afterwards if you want a picture — and you already have one, since ErdDocs draws the diagram itself.

What does the generated PlantUML contain?

One entity per table, primary key columns first and separated by a rule, then the rest. Keys are marked <<PK>>, <<FK>> and <<UK>>, mandatory columns carry PlantUML’s asterisk, and types keep the size and precision they were declared with. Relations are crow’s foot lines labeled with the foreign key column, and enums become enum blocks. The header sets hide circle and ortho line routing, so it looks like an ER diagram rather than a class diagram.

My dump has no foreign keys — Rails and Django often skip them.

ErdDocs then recovers the relations from column naming, so an author_id column links to the authors table. In the PlantUML output those lines are labeled "(by name)", so a reader can always tell a key the database declares from one that ErdDocs inferred. Nothing is silently invented.

Does it work with MySQL as well as PostgreSQL?

Yes. Paste pg_dump --schema-only output, mysqldump --no-data output, or plain CREATE TABLE statements; the dialect is detected from the text. MySQL AUTO_INCREMENT and inline COMMENT clauses, and PostgreSQL sequences, ALTER TABLE ONLY ... ADD CONSTRAINT idioms and COMMENT ON statements, are all understood.

Is it free?

Copying PlantUML is free at any schema size, with no account — the 25-table limit is on how many tables get drawn, not on what gets converted. The exported text carries one comment line naming ErdDocs; a $9 license removes it and lifts the size limit, and also unlocks the data dictionary.

Mermaid ER diagram generator — when the diagram belongs in a README instead.
PostgreSQL data dictionary generator — the same pg_dump file read as a document, COMMENT ON and all.
DBML to ER diagram — dbdiagram’s language, read and written.
Prisma schema to ER diagram — the database a schema.prisma generates.
Data dictionary generator — the same dump as a printable document.
Example schemas — eleven domains with SQL to paste.
SQL to ER diagram — the tool itself, with every format it reads.