ER diagram generator
Paste your CREATE TABLE statements and get an entity-relationship diagram — tables, columns, primary and foreign keys, and the lines between them. Download it as an .svg, or take the Mermaid erDiagram and paste it straight into a README. Free, no signup, and the SQL is parsed in this browser tab — it is never uploaded.
How it works
- Paste one
CREATE TABLEstatement or a whole schema dump. Anything that is not aCREATE TABLE— indexes, grants, inserts, comments, function bodies — is skipped rather than treated as an error, and SQL that appears inside a string (a migrations table storing its own DDL, say) is read as the data it is rather than as another table. - Each table becomes a box, each column a row in it, with
PKandFKmarked and the declared type on the right. - A foreign key is drawn as a line whenever the SQL says unambiguously which table it points at. Solid means
NOT NULL, dashed means nullable. The two cases that get named under the diagram instead of drawn: the target table is not in what you pasted, or it is in there more than once under different schemas and the reference did not say which. - Copy or download the SVG, or switch to the Mermaid tab for a block you can commit alongside the schema itself.
You drew the schema because you are about to ask it something
Nobody generates an ERD for its own sake. It comes out when you are new to a database and need to know what joins to what before you can ask it anything useful. Intellrise is the step after that: connect the same database, type your question, and get the chart back — and because it reads your schema the way this page just did, it knows which tables join to which without being told again. Every result carries a Show SQL toggle with the query it actually ran, because a number you cannot check is not an answer.
Intellrise is the one-stop AI data analyst for your own database or spreadsheet: one question becomes the SQL, the chart, a dashboard and a report, in one place. Every new account starts on a 14-day Pro trial with no card — nothing to enter, nothing to cancel — and lands on a permanently free tier after it lapses. Every plan, the trial included, needs an AI key; a Google Gemini key is free to create.
Frequently asked questions
No. The SQL is parsed by JavaScript running in this browser tab — there is no request carrying it, no account and no login. Close the tab and nothing of it remains.
The parser is deliberately lenient rather than dialect-locked: it handles the CREATE TABLE forms PostgreSQL, MySQL/MariaDB, SQL Server and SQLite emit, including quoted identifiers (double quotes, backticks, square brackets), typed parameters like numeric(10,2), inline and table-level PRIMARY KEY and FOREIGN KEY, and NOT NULL. It extracts what it recognises and ignores the rest, so a dump carrying vendor-specific storage clauses still draws — those clauses simply do not appear in the picture. Two things it reads and does not draw, because a box with them in would be a table rather than a diagram: DEFAULT expressions and MySQL column COMMENT — the data dictionary generator prints both. UNIQUE and CHECK are recognised and discarded rather than read, so nothing anywhere keeps them; that also means a UNIQUE on a foreign-key column, which would make the relationship one-to-one, is invisible here.
Only from foreign keys that are actually declared in the SQL you paste — inline (REFERENCES orders(id)), as a table-level FOREIGN KEY constraint, or attached afterwards by a separate ALTER TABLE … ADD CONSTRAINT statement, which is the form pg_dump and most scripted exports use. That last form matters more than it sounds: a dump writes every table first and every key second, so a parser that only looks inside CREATE TABLE ( … ) draws a diagram with no lines at all. This one reads all three, which is why pasting a whole dump works — including SQL Server's, where the key sits behind WITH CHECK ADD CONSTRAINT and the column carries an ASC. It is worth knowing because a great many production schemas relate tables by convention rather than by constraint: a column called customer_id with no FOREIGN KEY behind it is a relationship your team knows about and your database does not, and this tool will not draw it, because drawing it would mean guessing from a column name. If your diagram has fewer lines than you expected, that gap is the answer, and it is usually worth knowing.
A solid line is a NOT NULL foreign key — every row must point at a parent. A dashed line is a nullable one. That is the whole of what DDL tells you about optionality, so it is the whole of what is drawn. Cardinality beyond many-to-one is not shown, because CREATE TABLE does not state it: a one-to-one relationship looks identical to a many-to-one in the DDL unless there is also a UNIQUE constraint on the referencing column, and inferring it from that would be a guess dressed up as a reading.
Yes — the Mermaid tab emits a standard erDiagram block. GitHub and GitLab both render Mermaid inside a fenced code block in Markdown, so it draws in a README, a pull request or an issue without any extra step; anything else that renders Mermaid takes the same block, since there is nothing tool-specific in it. That is often more useful than the SVG, because it stays diffable in version control: when someone adds a table, the pull request shows one added block rather than a wholly different binary.
It stays marked FK on the column but is drawn without a line, and the page lists which ones below the diagram. That happens when you paste one file out of a multi-file schema. Paste the rest and the lines appear.
Then use the data dictionary generator — the same parser, but it produces a tables-and-columns reference with a place to write down what each field means, exportable as CSV or Markdown. And if you have a CSV rather than SQL and need the CREATE TABLE first, the CSV to SQL converter writes it for you.