How to make an ER diagram from SQL, without a database

Open the SQL to ER Diagram Generator and paste SQL like this:

```sql CREATE TABLE users ( id INTEGER PRIMARY KEY, email VARCHAR(255) UNIQUE );

CREATE TABLE orders ( id INTEGER PRIMARY KEY, user_id INTEGER NOT NULL REFERENCES users(id), total DECIMAL(10, 2) ); ```

You get an SVG with two table cards, id marked PK in each, user_id marked FK, and a line joining it to users.id.

There is no connection string and no account. The SQL is text, and reading text does not require a database — which is the whole reason this can happen in a browser tab at all.

Every item here was checked by running the parser against the real output of the tool named, not against simplified examples.

Table definitions

• CREATE TABLE and CREATE TABLE IF NOT EXISTS
• Names quoted with double quotes or backticks
• Schema-qualified names — CREATE TABLE public.users, which is how pg_dump writes every table. The schema is dropped from the label.
• Trailing table options — ) ENGINE=InnoDB DEFAULT CHARSET=utf8;, which is how mysqldump closes every table.

Keys and relationships

• Inline: user_id INTEGER REFERENCES users(id)
• Table-level: FOREIGN KEY (user_id) REFERENCES users(id)
• Declared afterwards: ALTER TABLE ONLY orders ADD CONSTRAINT fk_user FOREIGN KEY (user_id) REFERENCES users(id); — pg_dump puts foreign keys here rather than inside CREATE TABLE, often hundreds of lines further down the file.
• Composite primary keys: PRIMARY KEY (order_id, sku) marks both columns.
• NOT NULL, used to decide whether a column is shown as nullable.

Commas inside parentheses are left alone, so DECIMAL(10, 2) stays one type rather than becoming two columns.

A diagram that is wrong in a way you cannot see is worse than one that refuses to draw, so here is the boundary.

• It does not connect to anything. If your schema only exists in a running database, you need to export it first — mysqldump --no-data or pg_dump --schema-only both produce exactly the text this reads.
• It does not infer relationships that are not declared. A column called user_id with no REFERENCES and no foreign key constraint is drawn as an ordinary column, because guessing from a name is how diagrams acquire relationships that do not exist in the database.
• It does not read views, triggers, stored procedures or indexes. Tables and the keys between them only.
• It does not show cardinality. A foreign key is drawn as a line. Whether that relationship is one-to-many or one-to-one is not something REFERENCES tells you.
• It does not parse dialect-specific column syntax beyond the name and type. Postgres arrays, MySQL generated columns and similar are read as a type string and drawn as written.

A schema is a map of a business. Table and column names carry customer structure, pricing models, internal identifiers, and often the names of clients. Handing that to a web service to draw a picture is a larger disclosure than it looks, and for anyone working under an NDA or on a client system it is usually one they have not been given permission to make.

The tool is served with connect-src 'none', a Content-Security-Policy directive that tells the browser to refuse every outbound network request the page attempts. It is not a promise in a privacy policy; it is enforced by the browser, and you can check it yourself: open the network tab, paste a schema, generate a diagram, and watch nothing leave. Turning off your network connection entirely also works — the tool keeps running.

The output is an SVG, which matters more than it sounds. It is text, so it goes into a repository and diffs like code; it scales to any size without blurring, so it survives being dropped into documentation or printed at A3 for a wall; and it can be opened by any browser with no software installed.

Three themes: dark, light, and a navy-and-cyan blueprint. The dark one suits a README rendered on GitHub; the light one prints without emptying a cartridge.

A diagram generator reads FOREIGN KEY constraints and draws the edges they describe. The difficulty is that a large proportion of real schemas do not declare them.

Foreign keys are frequently absent for reasons that seemed sound at the time: MySQL's MyISAM engine never supported them; ORMs such as older Rails and Django configurations manage referential integrity in application code; sharded and distributed databases often cannot enforce cross-shard constraints; and teams disable them for bulk-load performance and never restore them.

When constraints are missing, relationships must be inferred from naming, and a small set of conventions covers most schemas:

• `<table>_id` or `<table>Id` referencing the singular or plural form of a table name — user_id to users.
• `fk_<table>` prefixes from schemas generated by older tools.
• Exact column-name matches where a non-primary-key column shares a name with another table's primary key.

Inference is a heuristic and should be shown as one. A diagram that draws a dashed edge labelled "inferred" is honest; one that draws inferred and declared relationships identically tells the reader something the schema does not say. The distinction matters when the diagram is being used to plan a migration, where a relationship the database does not actually enforce behaves very differently from one it does.

Cardinality — one-to-one, one-to-many, many-to-many — is not stated directly in DDL. It is deduced from which columns carry which constraints.

One-to-many is the default case: a foreign key column on the child table, not unique. Many orders rows may carry the same customer_id.

One-to-one is a foreign key that also carries a UNIQUE constraint, or one that is itself the primary key. user_profiles.user_id as both primary key and foreign key expresses exactly one profile per user.

Many-to-many is never a single relationship. It is a junction table whose primary key is a composite of two foreign keys:

CREATE TABLE course_enrolments (
  student_id INT NOT NULL REFERENCES students(id),
  course_id  INT NOT NULL REFERENCES courses(id),
  enrolled_on DATE NOT NULL,
  PRIMARY KEY (student_id, course_id)
);

A good diagram recognises that pattern and can collapse it into a single many-to-many edge, while still showing that the junction table carries its own attribute — enrolled_on here — because a junction table with extra columns is a real entity rather than pure plumbing.

Optionality comes from nullability. A nullable foreign key means the relationship is optional; NOT NULL makes it mandatory. Notation conventions differ, but crow's foot marks this distinction with a circle for optional and a bar for mandatory, and it changes how a reader understands the model.