From CREATE TABLE to a clear ER diagram

SQLViz · September 2026

Most teams do not have a schema diagram. They have a directory of migration files, a couple of stale wiki pages, and one person who remembers that orders.customer_id points at customers.id but is nullable for legacy rows. That works until someone new joins, or a foreign key cannot be added because the data has drifted, or you have to explain the whole data model in a meeting.

A diagram does not replace the migrations. It gives you the shape in one glance. Twenty tables with their relationships laid out tell you more in five seconds than scrolling a four thousand line migration file tells you in twenty minutes. The point is not prettiness, it is orientation: which table sits at the centre, which ones are lookups, and which ones are orphaned.

What the tool reads from your DDL

The parser works on CREATE TABLE statements. Paste them and it builds an interactive ER diagram from what is declared:

• tables and their columns, with data types
• primary keys, including composite keys and auto-increment
• foreign keys, both inline REFERENCES and table-level FOREIGN KEY clauses
• unique constraints and column defaults

MySQL, PostgreSQL and SQLite DDL are all supported, so the same paste works whether you exported with mysqldump --no-data or pg_dump --schema-only.

CREATE TABLE customers (
  id          INTEGER PRIMARY KEY AUTOINCREMENT,
  email       TEXT NOT NULL UNIQUE,
  created_at  TEXT DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE orders (
  id           INTEGER PRIMARY KEY,
  customer_id  INTEGER NOT NULL REFERENCES customers(id),
  status       TEXT NOT NULL DEFAULT 'pending',
  total_cents  INTEGER NOT NULL
);

CREATE TABLE order_items (
  order_id  INTEGER NOT NULL REFERENCES orders(id),
  sku       TEXT NOT NULL,
  qty       INTEGER NOT NULL,
  PRIMARY KEY (order_id, sku)
);

Paste, read, click

1. Paste the statements into the SQL to ER diagram tool. The diagram appears as you type. No signup, no upload.
2. Read the layout. Find the busiest nodes. A table that many others reference is your core entity. Tables that nothing points at are lookups or, more often, suspects.
3. Click a table to inspect its columns. Confirm types, check which columns are nullable, and see which ones are keys. This is where you catch a customer_id declared TEXT while customers.id is INTEGER, a join that works in some queries and fails elsewhere.

How to check the diagram is right

Do three passes, in this order.

Count the tables. Compare the number of boxes against the number of CREATE TABLE statements you pasted. If they differ, you pasted a partial schema, or one statement is wrapped in something the parser skips. Either way the diagram is lying to you, so fix that before trusting anything else.

Follow every foreign key. Read each arrow and ask whether the application actually relies on it. A delete path that fans out across four tables is worth knowing about before you run it in production.

Look for tables with no incoming relationship. This is the useful pass and the easiest one to skip. A table nothing references is either a lookup table or a table that other code joins to only in the application layer. Those are exactly where schemas drift. Someone adds invoice_id as a plain column, the join lives in an ORM query, and nothing in the database enforces it. Two years later you have orphan rows, and no foreign key error ever told you to care. Mark those tables and read the code that touches them.

One practical tip: paste the statements in dependency order, parents before children. It does not change what the parser finds, but it lets the layout settle into something readable on the first render, with the tables you care about near the top of the canvas instead of scattered after a re-layout.

Choosing an export

• SVG for docs. It is vector, so it stays sharp at any zoom and embeds cleanly in a wiki or an internal README.
• PNG for slides and chat. Drop it into a ticket or a chat thread and it renders everywhere without conversion.
• Mermaid for a repository. Commit the text and the diagram lives beside the code, so it is diffable in pull requests instead of being a stale image nobody updates.
• Normalized SQL for review. Handy when you are cleaning inconsistent formatting across a dump and want one canonical version to read.

The tool also exports Prisma schema, TypeScript and Python SQLAlchemy models, which helps when the diagram is the fastest route from an existing database to typed code.

The honest limit

A diagram shows what the DDL declares and nothing more. Relationships enforced only in application code will not appear. If invoices points at projects through a column with no foreign key, the diagram shows two unrelated tables and you may conclude the model is simpler than it is. It is a map of declared constraints, not of every join in your codebase. Read the two together.

Why client-side matters here

A production schema under NDA is not something you should paste into a random website. Table and column names leak the business. A payments table with a chargeback_reason column tells a competitor what you handle, and a table named enterprise_contracts tells them who you sell to. Sending that to an unknown server to get a picture is a bad trade.

SQLViz parses everything in your browser. The schema never leaves the machine, so you can diagram a client's database in the same tab where you read their documents. The PDF tools follow the same rule: merging PDFs without uploading them and compressing a PDF privately both run locally.

Start with one schema you already know well. Count the boxes, follow the arrows, and find the table nothing points at. That last one is usually where the real question lives.