Best on desktop — the editor needs a wider screen. Try ERDone on your laptop.

Docs

Concepts and capabilities for building schema designs in ERDone.

Design

How to build and refine schemas in the editor — tables, columns, relationships, indexes, and the views that keep large diagrams legible.

Tables and columns

  • Drag a table onto the canvas to create one. Click it to open the entity drawer.
  • Columns have a name, type, length / precision, and per-column flags: NOT NULL, primary key, UNIQUE, DEFAULT (any expression), IDENTITY / AUTO_INCREMENT (with seed and increment).
  • ERDone enforces “PK implies NOT NULL” — you can't produce invalid DDL by accident.
  • Auto-PK convention: a column named {TableName}Id is promoted to PK automatically on add or rename.
  • Table descriptions render as native SQL COMMENT per dialect.

Relationships

  • Drag from a parent (PK) column handle to a child column or table to create a relationship. ERDone creates the FK column (typed to match) AND a covering index automatically.
  • Identifying vs non-identifying relationships render as solid vs dashed lines.
  • Target cardinality: Many (0..), At least one (1..), Optional one (0..1), Exactly one (1..1).
  • Parent-required toggles the PK-end marker AND auto-syncs the FK column's NOT NULL.
  • Referential actions per relationship: ON DELETE CASCADE, ON UPDATE CASCADE (defaults to NO ACTION).
  • Re-aim a relationship's source (FK) or target (PK) column from the relationship drawer's dropdowns — no need to delete and redraw.

Indexes

  • Multi-column key columns with per-column ASC / DESC.
  • INCLUDE (covering) columns.
  • UNIQUE and CLUSTERED (T-SQL) flags.
  • WHERE filtered-index expression.
  • Auto-derived index names with manual override.
  • Every new FK column automatically gets a covering single-column index.

Visibility and Focus

  • Hide individual tables — table and its relationships disappear from the canvas, but stay in the SQL / JSON export.
  • Hide individual relationships — the line vanishes; both endpoint tables remain.
  • Toggle Focus in the StatusBar to dim every entity and edge that isn't directly related to the selected entity. Click related entities to traverse the local neighborhood.
  • Focus state persists across sessions.

Multi-diagram workspaces

  • Multiple diagrams per workspace with rename / delete / switch.
  • Each diagram carries its own dialect, visibility settings, and disabled-checks list.

Dictionary

The Dictionary is a left-side drawer that lets you browse every table, column, and relationship in one place — and triage health issues across the design.

Browsing the schema

  • Toggle the Dictionary drawer from the toolbar's dictionary icon. The canvas stays interactive while it's open.
  • Tabs: Tables / Columns / Relationships.
  • Each tab supports search and a “Hidden only” filter.

Health checks

Design-time validation that catches errors before they reach the database. Issues surface inline on the canvas, in the entity drawer header, and in the Dictionary's Health tab.

Errors (would fail or silently misbehave)

  • Empty table or column name
  • Table without a primary key
  • Duplicate column names within a table; duplicate table names within the diagram
  • FK column type doesn't match the referenced PK
  • Identity / AUTO_INCREMENT on a non-integer type
  • SQLite AUTOINCREMENT on a non-PK column

Warnings (likely modeling mistakes)

  • Same-named columns across tables with no FK between them
  • A column named {OtherTable}Id that isn't an FK
  • Orphan tables (no relationships)
  • FK columns with no covering index
  • Identifier matches a dialect reserved word
  • Foreign-dialect syntax in a default or expression — SQL Server brackets or GETDATE(), a MySQL backtick — when the diagram targets a different dialect

1-click autofix

Four health checks ship with a Fix button. All four go through the standard mutation pipeline, so ⌘Z reverts.

  • fk-no-index — adds a covering single-column index on the FK
  • fk-type-mismatch — copies the referenced PK column's type onto the FK
  • same-name-no-fk — creates the FK to the matching table's PK
  • fk-name-not-linked — creates the FK to the table named in the column ({Table}Id heuristic)

Disable rules per-diagram

Each rule can be silenced design-wide (for example, silence the same-named-FK warning for diagrams full of audit columns). The disable list persists with the diagram.

Pair with Claude (AI design review)

On Pro and Team, Pair with Claude sends your diagram's structure to Claude for a review of the design — naming, normalization, missing keys and indexes, modeling smells. It deliberately ignores SQL syntax and dialect nits; the deterministic health checks above own those.

Findings render as collapsible cards in a right-side drawer and in the Health tab — each one jump-to-able and individually dismissible. Dismissals persist per-diagram and stay suppressed on future runs. Results are cached per diagram and flagged stale when the schema changes. Launch it from the StatusBar.

Migrations

ERDone tracks what's deployed as a baseline snapshot and generates dialect-aware migration SQL when you change the design.

Concepts

Baseline
ERDone's record of what's currently deployed. The migration generator diffs against this.
Pending changes
Current diagram minus baseline. Visible as a chip in the StatusBar.
Mark as Applied
“I rolled this out to the canonical environment.” Advances the baseline.
Migration draft pointer
The file path of the in-progress migration in the repo. Multiple Save to Repo clicks update the same file until Mark as Applied or Discard Draft clears it.

Generate a migration

  • Edit the diagram. The pending change count appears in the StatusBar.
  • Open Migration Preview. The Changes tab lists every pending change individually.
  • Each row has a one-click ↩ revert button. Cascades are handled automatically — revert a column-add and any added relationships referencing it drop with it. Revert participates in undo / redo.

Save to repo

  • When connected to a GitHub repo, Save to repo writes a timestamped migration file: designs/{slug}/migrations/{YYYYMMDDHHMMSS}_{description}.sql.
  • Compatible with Flyway, dbmate, sqlx, golang-migrate, and Atlas out of the box.
  • The diagram remembers the file's path as a draft pointer. Subsequent saves overwrite the same file — one file per logical change, even across multiple edit / save cycles.

Mark as Applied

  • Once the migration file has been deployed, click Mark as Applied. This advances the baseline AND clears the draft pointer.
  • The next migration will only include changes you make from that point forward.

Import: Replace vs Merge

  • Replace All wipes the diagram and loads the pasted SQL as the new baseline. Use this when seeding from a fresh pg_dump.
  • Merge is additive — adds new tables / columns / indexes / relationships, updates matched ones, never deletes; preserves your local additions across re-imports. Use this when syncing a design after the DB drifts.

Per-dialect ALTER syntax

Each dialect emits its native form: Postgres' separate ALTER COLUMN TYPE / SET NOT NULL, MySQL's MODIFY COLUMN, T-SQL's named DF_ default constraints, Oracle's MODIFY (…). SQLite emits a comment for ALTER limitations it can't express in pure DDL.

Stable column / table / relationship IDs make rename detection exact — no fuzzy heuristic matching.

Workflows

Common job-aid workflows organized by role.

For DBAs

Roll out a schema change from dev → qa → prod

  1. Edit the diagram (add column, change type, etc.).
  2. Open Generate Migration → review changes on the Changes tab.
  3. Click Save to repo with a short description (e.g. “add user.last_login”).
  4. In your terminal: flyway migrate (or dbmate up, sqlx migrate run, etc.) against dev.
  5. If the dev migration succeeds, run the same file against qa, then prod — your migration tool tracks per-environment applied state in its own metadata table.
  6. Back in ERDone, click Mark as Applied to advance the baseline. The next migration will only include future changes.

Import an existing production schema and start designing changes

  1. Connect ERDone to your GitHub repo (or use local storage).
  2. Click Import SQL, paste your pg_dump --schema-only output (or equivalent).
  3. Choose Replace all objects. The pasted schema becomes the design AND the baseline simultaneously — you start at “zero pending changes.”
  4. Edit freely. Each change you make becomes a pending migration item, ready to generate.

Sync your design after the DB drifts (someone changed prod outside ERDone)

  1. Re-import the latest schema dump using Merge with existing. New tables / columns / index changes from the DB are absorbed into the design; your local pending edits are preserved.
  2. Open Migration Preview — the diff now shows BOTH the external changes and your local edits as pending.
  3. If you want to “accept the external changes as deployed,” click Mark as Applied to advance the baseline past the external changes, then continue editing — the next migration will contain only your changes.

Audit a design before sharing or committing

  1. Click the “N issues” chip in the StatusBar (or the toolbar's Dictionary icon → Health tab).
  2. Errors appear first (table without PK, duplicate names, FK type mismatch). Fix them.
  3. Warnings come next (missing FK indexes, columns that look like FKs but aren't linked, orphan tables). Click Fix on any of the four autofixable types.
  4. For warnings that are intentional in your domain (e.g., audit-trail columns that look like FKs but aren't), click Disable to silence that check across this design.

For application developers

Add a new entity for a feature

  1. Click + on the toolbar to add a table. Drag it where you want.
  2. Click the table to open the entity drawer. Type a name. Add columns (the first column named {TableName}Id auto-promotes to PK).
  3. To link it to an existing table: drag from the right edge handle of the parent table's PK column onto the body of your new table. ERDone creates the FK column (typed to match) AND a covering index automatically.
  4. Open Migration Preview → Save to repo → run via Flyway/etc.

Add a column to an existing table

  1. Click the table → entity drawer opens → click the column-add row at the bottom.
  2. Name it, set the type. If you named it {OtherTable}Id and there's no FK yet, Health will flag it — click the Fix button to wire the FK automatically.
  3. Migration will emit ALTER TABLE … ADD COLUMN.

Change a column's type or nullability

  1. Click the table → find the column → change type / toggle NOT NULL.
  2. Status bar shows “1 pending.”
  3. Migration Preview Changes tab shows: Customer.Email: type: VARCHAR(50) → VARCHAR(120).
  4. If you change your mind on a single attribute among many edits, click the ↩ next to that one row to revert just that change.

Refactor a relationship

  1. Click the relationship line on the canvas → relationship drawer opens.
  2. Re-aim source or reference column via the dropdowns (no need to delete + re-draw).
  3. Toggle identifying / cardinality / parent-required / on-delete-cascade as needed.
  4. Migration emits DROP CONSTRAINT FK_… then ADD CONSTRAINT FK_… FOREIGN KEY ….

Find and fix unindexed FK columns

  1. Open Dictionary → Health tab.
  2. Filter for “FK column has no covering index” warnings.
  3. Click Fix on each — one click adds IX_{Table}_{Column} covering the FK.
  4. Open Migration Preview to see the resulting CREATE INDEX statements.

For architects & data modelers

Document a data model for review

  1. Use the Dictionary drawer to scan all tables / columns / relationships in one place.
  2. Add table descriptions in the entity drawer (rendered as COMMENT ON TABLE in Postgres, native dialect equivalents elsewhere).
  3. Use the dialect picker in the StatusBar to switch the target DB and see the generated SQL re-emit per dialect.
  4. Generate the full schema via the toolbar's Generate SQL action — share the script for review.

Trace dependencies around a single entity

  1. Toggle Focus in the StatusBar.
  2. Click the entity you're investigating. The canvas dims everything not directly related.
  3. Click related entities (still full color) to traverse the local neighborhood. The focus shifts as you click; the dim/grayscale always pivots to the current selection's 1-hop graph.
  4. Toggle Focus off when done.

Plan a schema cleanup

  1. Open Dictionary → Health tab. Look for warnings like orphan-table (unused tables), reserved-word (identifiers that conflict with the dialect), same-name-no-fk (forgotten relationships).
  2. Use the Migration Preview's Changes tab to inspect the impact of any cleanup edits before generating SQL.
  3. For multi-step cleanups: edit, Save to repo (writes a draft file). Iterate further edits, click Update draft — same file in the repo gets the latest content. When ready, Mark as Applied to lock it.
Open the editor