A solo dev built an ER diagram tool that never sends your SQL anywhere — then a data engineer said it isn't ER

A schema visualizer where the schema never leaves the tab

sqltoerdiagram.com (340 points, 72 comments) is a one-person answer to a familiar annoyance. As its author put it in the Show HN: "most tools had the same problems: paywalls, mandatory signups, or sending your SQL to someone else's server. So I ended up building my own."

You paste CREATE TABLE statements and get an interactive entity-relationship diagram in the browser — tables, columns, primary and foreign keys, relationships. You drag tables, scroll to zoom, double-click to rename, auto-arrange the layout, add notes and group boxes, export to PNG or SVG, or share a link that encodes the whole diagram in the URL. It parses standard DDL across PostgreSQL, MySQL, SQLite, and SQL Server. The privacy line is the pitch: "100% local — your schema never leaves your browser. No accounts, no uploads."

The two implementation details the author was proud of

The author flagged two engineering decisions that earned the smoothness. Tables are rendered on a canvas, not the DOM, and "rasterized into cached bitmaps with viewport culling, which keeps things smooth even with hundreds of tables on screen." And the parser is span-aware:

"The SQL parser tracks source spans for every token. That lets edits stay surgical so a rename a table and only the relevant identifier (and its references) change…" — robhati, the author

That span-tracking is why renaming a column on the canvas can rewrite the underlying SQL precisely instead of regenerating it. A reader testing on mobile was startled: "100/10 for mobile usability. Panning, Zooming, selecting and moving was so seamless I thought I was tripping out."

"You can't get an ER diagram from SQL"

The sharpest pushback was conceptual, from someone who models data for a living:

"IMO you can't get an ER diagram from SQL since entities are fundamentally different from tables. They are certainly very similar, but SQL alone doesn't give you enough information to create an ER diagram." — michaelmior, Senior Data Engineer at OneChronos

He admitted to being pedantic. Another reader gave the working-developer rebuttal: "Perfect is the enemy of useful here. Most people aren't building ORM abstractions — they just want to see what's connected to what." Both are right, which is what makes the point worth keeping: the title says "ER diagram," the output is really a table-relationship diagram, and for 90% of users that gap doesn't matter.

A field full of these, and the feature requests that reveal real use

The thread became a roll call of adjacent tools — Azimutt, dbdiagram, wwwsqldesigner, MySQL Workbench ("remember… how clunky it was"), Mermaid's built-in ER support, and a complementary tool using sqlglot to translate between dialects. One blunt reader asked the question every Show HN gets in 2026: "did you use AI to assist with development? If yes, what percentage… is AI generated vs conventional?"

The feature requests said more than the praise. A Staff Engineer at Doctolib and others wanted CLI export so diagrams could live in a repo. One reader hit the multi-tenant problem head-on:

"in a multi-tenant application 90% of tables will link to the tenant table, but those links add little value… so hiding these would be nice." — CodesInChaos

And a 4k-karma reader noticed there's no LICENSE file in the repo — a small omission that quietly blocks anyone from depending on it.

The real product here is the trust model

Strip the diagram and what's left is a positioning bet: a developer tool whose entire value is that it does nothing on a server. No upload means no compliance review, no "can I paste our production schema into this." The "is it really ER" debate is the kind of correction that makes a tool better, not the kind that sinks it. The missing LICENSE file is the one that actually limits adoption — solve that, and a weekend project becomes something a team can put in its repo.