sqltoerdiagram: A Client-Side SQL to ER Diagram Generator
ER diagram generator. Paste CREATE TABLE statements and get a clean, interactive ERD — runs 100% in your browser, nothing uploaded
At a glance
- What is it?
- sqltoerdiagram is a single static page that parses CREATE TABLE statements into an interactive ER diagram entirely in the browser. Its two-dependency build and surgical text edits are the interesting parts; its SQL coverage and persistence model are the constraints.
- Who is it for?
- Adopt sqltoerdiagram if you need to turn an existing DDL dump into a shareable diagram without installing a database client or sending a schema to a third party, and if your DDL stays close to CREATE TABLE with FOREIGN KEY constraints. Do not adopt it if you need migration tooling, schema diffing, or a committed diagram file that survives a browser change.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 60 days ago.
- What is it written in?
- Mainly HTML, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap sqltoerdiagram fills: DDL in, diagram out, no upload
Most schema visualisation tools sit behind an account, a paid tier, or a server round trip. sqltoerdiagram takes the opposite position. The README describes it as a single static page that runs entirely in the browser, with the schema never leaving the machine. That constraint drives every other design decision in the project.
The target user is an engineer who already has DDL, typically a pg_dump or a mysqldump, and wants a picture of it without standing up a database. The tool accepts pasted CREATE TABLE and ALTER TABLE statements rather than a live connection string. There is no schema introspection path, no credentials to configure, and nothing to install beyond a browser. A second audience appears in the BigQuery mode: an analyst pasting a WITH ... AS (...) query and getting each CTE rendered as a table node, with edges inferred from FROM and JOIN references. That is a different workflow from DDL diagramming, and the README treats it as a separate dialect selection rather than a separate tool.
How the parser and canvas renderer actually work
The architecture has two halves. A custom SQL DDL parser, written without a heavy parser dependency, turns the pasted text into tables, columns and foreign key edges. A canvas renderer draws them, using cached bitmaps plus viewport culling. The README states the project depends on @dagrejs/dagre for layered auto-layout and Vite for the build, and that the resulting bundle is 32KB gzip with a dependency count of two. That is unusually lean for a tool that parses SQL and lays out graphs.
The supported surface is narrower than a full SQL grammar. The README lists CREATE [OR REPLACE] [TEMPORARY | TRANSIENT] TABLE [IF NOT EXISTS] with quoted, backtick, [bracket] and schema.qualified names. Inline constraints cover PRIMARY KEY, NOT NULL, UNIQUE and REFERENCES other(col). Table-level PRIMARY KEY, UNIQUE, FOREIGN KEY (...) REFERENCES other(...) and CONSTRAINT ... FOREIGN KEY ... are handled, along with ALTER TABLE x ADD [CONSTRAINT ...] FOREIGN KEY. Line comments with -- or # and block comments are ignored. Anything outside that list is not claimed.
The editing model is the part worth reading closely. Double-clicking a table name, column name or column type applies what the README calls a surgical text edit, meaning comments, formatting and unsupported clauses are preserved rather than regenerated from an internal model. A table rename propagates to every REFERENCES clause pointing at it. Adding a column inserts a statement into the SQL text with a default type for the selected dialect. This is a text-preserving design, and it is a deliberate contrast to tools that round-trip your schema through their own representation and hand back a normalised version.
Running it locally and hosting the static build
The README gives two command pairs. For local development: npm install, then npm run dev, which serves http://localhost:5173. For production: npm run build, which outputs static files to dist/, then npm run preview to check the production build locally. The dist/ directory is plain static HTML, JS and CSS, and the README lists GitHub Pages (push dist/ to a gh-pages branch or use an action), Netlify, Vercel and Cloudflare Pages with build command npm run build and publish dir dist, plus any web server or S3 bucket.
There is no server-side component to configure, no environment variables, and no database connection string. That is the whole deployment story. The persistence model runs on browser storage and URLs instead of a backend: Save downloads a .json project containing SQL, layout, camera position and dialect; Open loads one back. Share copies a URL with the entire project encoded in the hash fragment, gzip-compressed and base64-encoded. The README notes the # fragment is never sent to a server, which is why sharing works without one. Positions and camera state also persist automatically so a reload restores the layout.
The keyboard surface is small: Cmd or Ctrl plus Enter re-arranges, double-clicking empty canvas zooms in, and dragging the pane divider resizes the editor.
Where the model breaks: parser coverage and hash-length limits
The parser is the first constraint. It handles the DDL forms the README enumerates, and the README does not claim general SQL support. A schema that relies on CHECK constraints, GENERATED columns, partial indexes, triggers, views or functions will render, but those constructs are not part of the documented grammar. The project also has no schema diffing, no migration generation, and no connection to a live database, so it cannot answer what changed between two versions of a schema.
The share link is the second constraint, and it is the more interesting one. Encoding an entire project into a URL hash means the URL grows with the schema. The README does not state a length ceiling, and browsers and chat clients differ in how much they tolerate. For a schema of hundreds of tables, the gzip plus base64 payload is likely to be a very long URL, and the documentation offers no guidance on where that stops working. Anyone planning to circulate links for a large schema should test that path before depending on it. The .json project file has no such limit, so Save and Open is the safer channel for large models.
A third limitation is storage scope. Layout, camera and the last schema live in browser storage, which is per-browser and per-profile. There is no account, so there is no cross-device sync. The README presents this as a feature, and for privacy it is, but it also means a cleared browser profile loses the working state unless a .json was saved.
How it differs from dbdiagram.io and DBML-first tools
The closest comparison in the project's own topic list is dbdiagram, and the difference is the input format. DBML-first tools ask you to author a dedicated schema language, then generate SQL or a diagram from it. sqltoerdiagram goes the other direction: SQL is the source of truth, and the diagram is a view of it. If your schema already exists as DDL, the DBML route means a translation step, and that translation can drift from the real schema. The README's own framing is that the tool accepts pasted CREATE TABLE statements rather than requiring you to learn a new syntax.
The second difference is where computation happens. A hosted diagramming service renders on a server, which means the schema is transmitted. sqltoerdiagram parses and draws locally, and the README states nothing is uploaded. For schemas under NDA or in regulated environments, that distinction may decide the choice regardless of feature parity.
The trade-off is ecosystem. A DBML tool typically offers a CLI, version-controllable diagram source, and integrations. sqltoerdiagram offers a browser page, a .json project file, and PNG or SVG export. The exported image is a snapshot, not a regenerable source. If you want diagrams that rebuild in CI from a committed file, this is not that tool.
Maintenance surface and the MIT licence
The dependency count is the maintenance argument. Two runtime dependencies, @dagrejs/dagre and Vite, mean the upgrade surface is small and the supply chain exposure is limited compared with a tool pulling in a full SQL parser and a rendering framework. The README explicitly notes there is no heavy SQL-parser dependency, which is why the supported grammar is what it is. That is a coherent trade: less to break, less coverage.
The repository is HTML-primary with a Vite build, is not archived, and carries the MIT licence with copyright to Royal Bhati. The README invites forking, self-hosting and adding your own SQL dialects. MIT permits that, including commercial use and redistribution, provided the copyright notice and permission notice are retained. This is a description of the licence text, not legal advice; if you plan to redistribute the tool inside a product, read the LICENSE file in the repository and take your own counsel on attribution.
There are no published releases in the material provided, so there is no versioned changelog to track. Upgrades mean pulling from main. For a self-hosted deployment that is a real consideration: you inherit whatever is on the branch at the moment you build. Pinning to a commit hash is the obvious mitigation, and the README does not discuss release tagging.
Verifying sqltoerdiagram against your own schema
The honest test is your own DDL. Paste a production-shaped CREATE TABLE script, not a toy example, and check three things. First, that every foreign key you expect appears as an edge; the parser only recognises the constraint forms the README lists, so a schema using an unusual syntax may silently lose relationships. Second, that inline edits preserve your comments and formatting, since the surgical edit model is the feature most likely to surprise someone expecting a normalising round trip. Third, that a Share link for your largest realistic schema opens in a different browser and restores the layout, because the URL-hash encoding has no documented size limit.
For BigQuery users the check is different: paste a WITH ... AS (...) query and confirm each CTE becomes a node, that column names come through with aliases applied, and that references to base tables produce stub nodes as the README describes. The BigQuery path infers relationships from FROM and JOIN references rather than declared constraints, so its edge set is a different kind of claim than the DDL path's.
The project is a single static page with a small dependency tree and a clear scope. Treat it as a viewer for DDL you already have, not as a schema management system, and the gap between what it claims and what it does stays small.
Editorial conclusion
Adopt sqltoerdiagram if you need to turn an existing DDL dump into a shareable diagram without installing a database client or sending a schema to a third party, and if your DDL stays close to CREATE TABLE with FOREIGN KEY constraints. Do not adopt it if you need migration tooling, schema diffing, or a committed diagram file that survives a browser change. Before relying on it, verify that your CREATE TABLE statements parse without loss, test that a Share link opens correctly in a different browser, and confirm the MIT licence terms suit your distribution plan.
Community notes