How it works

Updated 2026-10-30

This is the shape of a project in ERDism, in the order you meet it.

1. A workspace holds your projects

You sign up, and you get a workspace. A workspace holds projects, and a project holds diagrams. Members are invited to the workspace and carry a role there, so access is decided once rather than per project.

2. A project is one schema

Inside a project you open the editor. The canvas is the diagram, the panel under it is the SQL, and the panel beside it is the inspector where you edit properties, read the timeline, and see issues. They are three views of one model, so a change made in any of them shows up in the other two.

A project can have several diagrams over the same tables. A table lives once in the project and can be placed on as many diagrams as you like, so each team can keep a view of the part it works on.

3. You import the schema you run, or draw a new one

Importing means pasting SQL or uploading a file. Import runs in three steps: analyze, which reports what the SQL says and which tables it would add or change; confirm, where you choose which tables go on which diagram and agree to anything the import would remove; and import, which applies it. Clauses ERDism does not model are kept as written.

Drawing means placing tables on the canvas, adding columns and keys, and drawing relationships between them. ERDism writes the CREATE TABLE for each table as you go.

4. You explain it

Each table has doc pages you write in Markdown. They stay with the table, so whoever opens it next reads the explanation next to the columns.

5. Every change is recorded

The timeline records each change with who made it and when: tables and columns added, updated, deleted, and restored, and SQL blocks approved, rejected, and published. Undo and Redo act only on your own changes, and they reach every diagram in the project rather than one diagram at a time.

6. Changes are reviewed

Editing a table produces a draft. Drafts are saved when you save them, and each SQL block carries an approval state until a teammate approves or rejects it. The server checks the schema against the database and version the project targets, and anything that version does not support shows up as an issue.

7. You publish, then export

Publishing takes the approved SQL and records it as a published version. Publishing is gated on the schema being ready: blocks approved, no unresolved relationships, and a supported dialect. Once published, you can export the SQL as a file. Today that is the full schema; ERDism does not yet write the ALTER statements between two versions.

While other people are in the same project

When someone selects or edits a table or a SQL block, everyone else sees it marked as taken, and the block is read-only for them until it is released. This is mutual exclusion, not merging: two people never edit the same table at the same time.