erd.sketch 將 SQL schema 轉為可編輯圖表

A SQL schema tells you what exists in a database. Understanding how everything connects takes more work: following foreign keys, jumping between table definitions, and keeping relationships in your head.

I built erd.sketch to make that process visual. Paste a schema, build a diagram, and explore the relationships. You can then edit tables on the canvas, check the schema, and generate code from it.

The main design decision is that SQL stays at the center. The diagram is another way to work with the schema, and edits made through the table cards update the SQL.

You can open the editor.

A small example

Here is a deliberately simple schema to try:

CREATE TABLE customers (
  id BIGINT PRIMARY KEY,
  email VARCHAR(255) NOT NULL UNIQUE
);

CREATE TABLE orders (
  id BIGINT PRIMARY KEY,
  customer_id BIGINT NOT NULL,
  total NUMERIC(12, 2) NOT NULL,
  FOREIGN KEY (customer_id) REFERENCES customers(id)
);

Paste it into the SQL panel and build the diagram. You get two table cards connected by a one-to-many relationship: a customer can have multiple orders.

From there, you can move the cards, inspect the relationship, add or edit columns, and rename a table. Renaming also updates references to that table in the script.

This example intentionally leaves out an index on orders.customer_id. The schema checker flags the missing foreign-key index and offers a fix that adds a CREATE INDEX statement. It also highlights the unspecified ON DELETE action as something to consider.

Those checks are useful during design, when the schema is still easy to change. They are suggestions to evaluate in context; for example, a nullable foreign key can be entirely intentional.

Beyond the diagram

The editor accepts SQL DDL, DBML, and Prisma schemas. DBML and Prisma imports are converted into SQL, with notes for constructs that do not transfer.

Once a schema is loaded, you can:

• Generate Prisma, TypeORM, SQLAlchemy, or GORM models.
• Generate TypeScript, Java, Go, C#, or Rust types and classes.
• Compare two schema versions and produce migration SQL.
• Export the diagram as SVG, PNG, or PDF.
• Add notes, search tables and columns, and organize tables by database schema.

Code generation works for an individual table or the whole schema. Migration generation uses the detected target dialect and reports operations it cannot express. Both outputs are starting points for review: the editor does not connect to a database to execute them.

SQL as the source of truth

One implementation detail shaped much of the application: the parsed schema model is derived from SQL rather than persisted as a second, independent schema definition.

The saved document contains the SQL alongside canvas state such as table positions, card widths, and notes. When the document is loaded, the model is rebuilt from the last SQL used to build the diagram.

There is also a distinction between the text currently being edited and the script behind the current diagram. Typing half a statement does not need to become a diagram edit immediately.

That distinction carries through to undo. Typing uses the text field's own undo behavior; building the diagram creates a document-history step. Dragging a card creates one step when the drag ends, rather than a step for every pointer movement.

Local storage, with optional online features

Documents start in the browser's local storage. Parsing, visual editing, schema checks, and code generation happen locally.

Online features have separate data paths. Enabling cloud storage uploads the document for synchronization and sharing. Using the built-in AI assistant sends schema context through the backend to the model provider.

For shared cloud documents, the project includes presence indicators, remote cursors, and live table movement. Saved schema changes are synchronized using document versions. Conflicting edits require resolution; this is not yet a CRDT-based editor that merges simultaneous changes automatically.

Even local storage needed coordination. Two tabs can otherwise overwrite the same document. The editor uses Web Locks to choose one tab to persist a document, and BroadcastChannel to exchange changes between tabs. Browsers without Web Locks fall back to the simpler behavior.

Try it with your schema

The most useful feedback now is a real schema that exposes a gap: an import that loses information, a relationship that renders incorrectly, or generated code that needs too much manual cleanup.

Try erd.sketch

When you open an unfamiliar database schema, what do you want to understand first: the relationships, potential design problems, or the code you can generate from it?